WordPress 500 Error Only on Wi‑Fi? Fix It Fast (Router, DNS Filtering, TLS Inspection)

Quick answer: A WordPress 500 error only on Wi‑Fi is usually caused by the Wi‑Fi network (DNS filtering, router firewall, proxy/TLS inspection) or a device/browser state problem—not your WordPress code.

Confirm which it is by testing the same URL on a hotspot and in a clean browser session, then follow the matching branch below.

Quick Fix Checklist

Do these in order; each step tells you what the result means.

• 1) Capture the exact symptom (don’t guess):
  • Is it the whole site (homepage) or only wp-admin / specific actions (login, publish, media upload)?
  • Note the exact URL, time, and whether it’s a browser error page or a WordPress/host error page.
• 2) Switch networks (fastest classifier):
  • Open the same URL on mobile data/hotspot.
  • Works on hotspot → prioritize Wi‑Fi/router/DNS filtering.
  • Fails everywhere → prioritize server/plugin/theme and logs.
• 3) Switch device on the same Wi‑Fi:
  • Multiple devices fail → it’s almost certainly network policy/router.
  • Only one device fails → it’s likely browser/app state, VPN/proxy, local firewall.
• 4) Private mode test:
  • Works in incognito/private but not normal mode → suspect cookies/session, extensions, corrupted local storage, or a stuck service worker.
• 5) Switch browser/app:
  • If only one browser fails, focus on extensions, site data, and secure DNS/proxy settings in that browser.

Quick classification (pick the closest match):

• A) Can’t sign in on Wi‑Fi: login loop, 500 after submitting credentials, “session expired,” or cookies not sticking.
• B) Page loads but actions fail: editor won’t save, media upload fails, REST API errors, admin screens partially broken.
• C) Whole site shows 500 only on Wi‑Fi: homepage and wp-admin fail on Wi‑Fi but work on hotspot.
• D) Only one device fails: same Wi‑Fi works on other devices.
• E) Started after a change: plugin/theme update, router setting change, new extension, new VPN, or DNS/security feature enabled.

Causes (realistic, not generic)

A 500 error is “server error,” but when it happens only on Wi‑Fi, the trigger is often upstream of WordPress or specific to one client.

• Network filtering, proxy, or TLS inspection: Corporate/school Wi‑Fi, “web protection” routers, or security gateways can intercept HTTPS and break WordPress requests (REST API, admin-ajax, editor calls).
• DNS filtering or router security rules: Router-level ad blocking/safe browsing/parental controls can block required domains or paths, causing admin actions to fail.
• VPN or proxy interference: A device VPN/proxy can behave differently on Wi‑Fi vs mobile data (different routes, MTU, or DNS), causing handshake failures or blocked endpoints.
• Corrupted local storage, cache, or service worker: Stale cached assets or a stuck service worker can break wp-admin screens in normal mode.
• Browser extension or app overlay conflict: Privacy/ad-block/script-block extensions can block /wp-json/, admin-ajax.php, cookies, or headers.
• Blocked WebSockets/HTTP2 streaming transport: Some networks block WebSockets or certain HTTP/2 behaviors used by plugins, editors, or real-time features.
• Temporary service outage or degraded backend: Less common for true Wi‑Fi-only issues, but possible if Wi‑Fi DNS routes you to a different CDN/WAF edge with problems.
• Captive portal / “walled garden” Wi‑Fi: You can browse some sites, but authenticated/admin requests fail until you complete the portal login.

What you observe	Most likely cause	Best next fix
Works on hotspot, fails on Wi‑Fi (multiple devices)	Router firewall/DNS filtering/TLS inspection/captive portal	Change DNS, complete captive portal, disable HTTPS inspection/security filtering, allowlist domains
Works in incognito, fails in normal mode	Cookies/local storage/service worker/extension conflict	Clear site data, unregister service worker, disable extensions for the site
Homepage loads, but wp-admin actions fail (save/upload)	Blocked REST API/admin-ajax, WAF/rate limits, blocked WebSockets	Check DevTools Network, allowlist /wp-json/ and admin-ajax.php, check WAF/host logs for 403/429/5xx
Only one device fails on the same Wi‑Fi	Device VPN/proxy, secure DNS, cached state, local firewall	Disable VPN/proxy/secure DNS, clear site data, reset network settings
Started right after plugin/theme update or cache change	Plugin conflict, cache layer mismatch, REST API blocked	Disable caching/security plugins, purge all cache layers, isolate plugin/theme, review server logs

Step-by-Step Fix

Follow the branch that matches your classifier (A–E). Each step is meant to confirm or eliminate a cause.

Branch C: Whole site shows 500 only on Wi‑Fi (network-first)

• 1) Confirm it’s the Wi‑Fi network (not the device):
  • Test two devices on the same Wi‑Fi.
  • If both fail but hotspot works, stop changing WordPress settings and focus on the network.
• 2) Detect DNS filtering quickly:
  • Temporarily set DNS to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) on the device or router.
  • Flush DNS cache (Windows: ipconfig /flushdns; macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder).
  • If the 500 disappears, your previous DNS/router filtering was interfering. Keep the working DNS or disable the router’s DNS filtering feature.
• 3) Check captive portal / policy Wi‑Fi:
  • Open http://neverssl.com to see if a captive portal intercepts traffic.
  • If a portal appears, complete it, then retry WordPress.
• 4) Disable router “security” features that commonly break WordPress:
  • Temporarily turn off: “HTTPS scanning/inspection,” “Web protection,” “Ad blocking,” “Safe browsing,” “Parental controls,” “Intrusion prevention,” or “DoH/secure DNS filtering.”
  • Retry the site. If fixed, re-enable features one by one to find the exact setting.
• 5) Advanced: test IPv6 vs IPv4 (non-obvious but common on some routers):
  • Temporarily disable IPv6 on the router or device, then retest.
  • If disabling IPv6 fixes it, your ISP/router IPv6 path or DNS64/NAT64 setup may be breaking TLS or routing to a bad edge.
• 6) Uncommon but realistic: MTU mismatch on Wi‑Fi/VPN path:
  • If you use a VPN, disable it and retest.
  • If the issue only happens with VPN on Wi‑Fi, set a lower MTU on the VPN profile (often 1280–1420) or adjust router WAN MTU if you control it.
  • MTU symptoms: requests hang, intermittent 500/timeouts, admin actions fail while simple pages sometimes load.
• 7) Allowlist required domains/endpoints (if you manage the network):
  • Allowlist your WordPress domain and any CDN/WAF domains (Cloudflare/Sucuri/etc.).
  • Ensure these paths are not blocked: /wp-admin/, /wp-json/, /wp-admin/admin-ajax.php.
  • If TLS inspection is enabled, exclude your WordPress domain from inspection if policy allows.

Branch D: Only one device fails on the same Wi‑Fi (device/browser state)

• 1) Clear only this site’s data (targeted):
  • Remove cookies, cache, and site storage for your WordPress domain (not your whole browser).
  • Retry the failing page and wp-admin login.
• 2) Remove a stuck service worker (common with caching plugins/PWA setups):
  • Chrome/Edge: DevTools → Application → Service Workers → Unregister.
  • Then Application → Storage → Clear site data, and hard reload (Ctrl+Shift+R / Cmd+Shift+R).
• 3) Disable extensions that can block WordPress transport:
  • Temporarily disable ad blockers, privacy/script blockers, antivirus “web shield,” and password managers with aggressive overlays.
  • If it fixes the issue, allowlist your domain (especially /wp-admin/ and /wp-json/).
• 4) Check device proxy/VPN/secure DNS settings:
  • Ensure no manual proxy is set for the Wi‑Fi network.
  • Disable VPN and any “secure DNS”/DNS filtering apps temporarily and retest.
  • If you must keep secure DNS, try switching providers (some block admin endpoints or CDN subdomains).
• 5) Reset the network stack (when Wi‑Fi-only issues persist on one device):
  • Forget the Wi‑Fi network and re-join.
  • Optionally reset network settings (especially on iOS/Android/Windows) if the device has a history of VPN/proxy profiles.

Branch A: Can’t sign in on Wi‑Fi (account/session path first)

• 1) Confirm it’s session/cookie related:
  • If incognito works but normal mode doesn’t, it’s almost always cookies/site data or an extension.
• 2) Fix cookie + hostname mismatches:
  • Always use the same hostname: https://example.com vs https://www.example.com (switching can break cookies).
  • Clear cookies for the WordPress domain, then sign in again.
• 3) Check time/date and captive portal (surprisingly common):
  • If the device clock is wrong, TLS and sessions can fail. Set time to automatic and retry.
  • On public Wi‑Fi, complete the captive portal login first (see Branch C step 3).
• 4) If you manage the site: check WAF/rate limits triggered by the Wi‑Fi IP:
  • Security plugins/WAFs can block repeated logins from a shared Wi‑Fi public IP (coffee shop, office), sometimes surfacing as 500/blocked responses.
  • Check security plugin logs and host/WAF events for your Wi‑Fi public IP; allowlist it temporarily to test.

Branch B: Page loads but actions fail (REST API / transport)

• 1) Identify the failing request (don’t rely on the 500 page):
  • Open DevTools → Network, reproduce the issue (save post/upload media).
  • Look for failing calls to /wp-json/, admin-ajax.php, async-upload.php, or plugin endpoints.
  • Note the status code: 403 (blocked), 429 (rate limited), 5xx (server/WAF/upstream), or (failed) (network/TLS).
• 2) If failures happen only on Wi‑Fi:
  • Suspect router firewall, DNS filtering, TLS inspection, or blocked WebSockets.
  • Try Branch C steps 2–5 (DNS, captive portal, disable inspection/filtering, IPv6 test).
• 3) If failures happen on all networks (site-side):
  • Temporarily disable caching/security/optimization plugins (minify/combine, REST API restrictions, WAF rules) and purge all server-side cache layers (host cache, CDN cache, object cache).
  • Retest. If fixed, re-enable one component at a time to find the conflict.
• 4) Check REST API permissions and server logs:
  • In server logs, look around the timestamp for patterns on /wp-json/ and admin-ajax.php: repeated 403, 429, or 5xx.
  • If you see 429, reduce aggressive background requests (some plugins poll frequently) or adjust WAF/host rate limiting.
  • If you see 403, check WAF rules, security plugin blocks, and router filtering.

Branch E: Started after an update or settings change (plugin/theme isolation)

• 1) Purge every cache layer first: Browser cache, plugin cache, host cache, and CDN cache. Different networks can hit different cached edges, making it look “Wi‑Fi-only.”
• 2) Test with a default theme: Switch temporarily to a default theme (e.g., Twenty Twenty-Four) to rule out theme-level fatal errors.
• 3) Plugin conflict isolation path:
  • Disable all plugins, then re-enable in small groups until the 500 returns.
  • Pay special attention to caching, security, optimization, editor, and firewall/WAF integration plugins.
• 4) If you changed router/DNS/security settings: Roll back the last change (DNS filtering, HTTPS inspection, ad blocking, parental controls) and retest.

Still Not Working

If you’ve isolated the branch but the fix isn’t obvious, collect evidence and test edge cases so your host or network admin can act quickly.

• Get the real failing status and endpoint:
  • In DevTools → Network, click the failing request and record: URL, status code, and any error like ERR_SSL_PROTOCOL_ERROR, net::ERR_CERT_AUTHORITY_INVALID, or blocked by client.
  • If you see certificate errors on Wi‑Fi only, that strongly suggests TLS inspection or a captive portal intercepting HTTPS.
• Check server-side logs (site owners):
  • Review web server error logs + PHP error logs at the exact time of failure.
  • Look for fatal errors, memory exhaustion, or upstream/WAF blocks tied to your Wi‑Fi public IP.
• Compare DNS answers (detect filtering or bad edge routing):
  • Run nslookup yourdomain.com (or dig) using your router DNS vs 1.1.1.1.
  • Different results can indicate filtering, split-horizon DNS, or a broken CDN/WAF edge for one resolver.
• Test with a direct IP path (advanced, only if you know what you’re doing):
  • If you use a CDN/WAF, temporarily pause it (or use a host-provided bypass URL) to see if the 500 is coming from the edge.
  • Don’t leave bypasses enabled; use them only for isolation.
• Edge cases that mimic “Wi‑Fi-only 500”:
  • Router ad blocker blocks a script needed for wp-admin, causing actions to fail while pages load.
  • HTTP/3 (QUIC) issues on some networks: disable QUIC/HTTP3 in the browser flags/settings (or test another browser) to isolate.
  • Large uploads fail only on Wi‑Fi: test a small file vs large file; if only large fails, check router QoS/security scanning and server upload limits.
• Escalation steps (what to send and who to contact):
  • If it works on hotspot but fails for multiple devices on one Wi‑Fi: contact the network admin/ISP. Provide: your domain, timestamp, your Wi‑Fi public IP, and whether TLS inspection/ad blocking is enabled.
  • If it fails on all networks and logs show 5xx: contact your host with timestamps, failing endpoints (/wp-json/, admin-ajax.php), and relevant log excerpts.
  • If only one browser profile fails: create a fresh browser profile (or reinstall the app) to eliminate corrupted profile state.
  • If only one device fails after all steps: reset network settings and remove any installed VPN/proxy profiles, then retest.

If you contact your host or network admin, ask them to check for WAF blocks, TLS inspection, rate limiting, and blocked paths affecting wp-admin, /wp-json/, and admin-ajax.php from your Wi‑Fi public IP.

Frequently Asked Questions