App Not Connecting to Internet: Diagnosis Guide

"The app does not work" from users often means "the app can't reach the internet." The causes span device, network, OS, carrier, server, and client code. Methodical diagnosis is faster than guessing.

"The app does not work" from users often means "the app can't reach the internet." The causes span device, network, OS, carrier, server, and client code. Methodical diagnosis is faster than guessing. This guide covers the ladder.

Symptoms

• Blank screens where data should be
• Infinite spinner
• Timeout errors
• "Unable to connect" messages
• Features silently missing
• Some screens work, others do not

Diagnostic ladder

Start at the device, go outward.

1. Is the device actually online?

Open any other site. Works? Move on. Does not? Their network issue.

2. Is airplane mode / Wi-Fi off?

Quick-setting check. Silly but common.

3. Is the OS's own connectivity good?

Settings → connection test. DNS working? Gateway reachable?

4. Is your app's domain reachable?

ping yourapi.com from the device (or browser). If not, their DNS / firewall blocks.

5. Is it HTTPS working?

Some corporate / captive networks strip HTTPS or require certificate install. Try http://example.com vs https://yourapi.com.

6. Is there a VPN / proxy?

VPN that fails to route app traffic. Common cause especially in corporate environments.

7. Is the app's SSL pinning mad at the MITM proxy?

If user has a debugging tool / corporate MITM installed, pinning rejects.

8. Is the server returning expected responses?

Curl from your machine. Is your API returning 200?

9. Is the server specifically rejecting this user?

IP-based rate limit, geoblocking, account-level ban.

10. Is the client-side timeout too aggressive?

5-second timeout on mobile LTE is marginal. 20-second is reasonable.

Common causes

Captive portal

User on hotel / airport Wi-Fi. Network "connected" but not authenticated. Any HTTPS request fails or redirects.

Detection: Your app should detect captive portal (failed connect + HTTP redirect response) and prompt user to authenticate.

DNS propagation

Your domain changed IP (migration, CDN update). Some users' DNS caches still point at old.

Mitigation: Multiple DNS providers, low TTL, monitor DNS propagation.

IPv6 vs IPv4

Some networks are IPv6-only. If your API does not support IPv6, those users fail.

Fix: Server listens on IPv6 and IPv4. Test on IPv6-only carriers.

Carrier blocking

Some carriers block ports (non-80/443) or protocols (VoIP, VPN). Your server on port 8443 may be unreachable for some.

Fix: Use standard ports. Keep API on 443.

App's certificate expired

Cert pinning pinned to an older cert. New cert deployed server-side; app rejects.

Fix: Pin to the CA (root or intermediate), not leaf. Or renew pin in app before cert expires.

Client code: wrong URL

api.staging.example.com used in a release build by mistake. Staging offline or inaccessible.

Fix: Build configurations enforce correct URL per build variant. CI check.

OS-level restrictions

Android 10+ restricts background network access in data saver / battery saver. App's background sync fails.

Fix: Foreground sync only, or handle the restriction gracefully.

Ad-blockers / privacy apps

User has AdGuard, Pi-hole, or privacy DNS that blocks your tracking / analytics domain. Legitimate feature requests to api.yourapp.com go through; analytics to tracking.yourapp.com do not.

Fix: Do not depend on analytics to be reachable. Feature flags should be first-party.

Corporate firewall

Enterprise user on corporate Wi-Fi. Firewall blocks your API.

Fix: Use standard ports. Document firewall requirements. Provide self-hosted option if enterprise market.

Fix patterns

• Detect and surface: clear "connection problem" state with retry, not spinner forever
• Exponential backoff: retry 1s, 2s, 4s, 8s. Give up after reasonable time.
• Offline mode: cached content visible with "Last updated X" indicator
• Queue writes: actions taken offline replay on reconnect
• Different error for different failure: timeout ≠ 401 ≠ DNS failure

How SUSA tests connectivity

SUSA's network_tester runs these conditions during exploration:

• Slow 2G (throttled bandwidth)
• High latency (500ms+ added)
• Packet loss (20% drop)
• Offline (airplane mode)
• Network recovery (offline → online cycle)

Each flags how the app behaves. Finding: flows that fail on high latency but pass on fast Wi-Fi, actions that silently drop on offline, stuck loaders on packet loss.

susatest-agent test myapp.apk --network high_latency --steps 100

Prevention

• CI regression with throttled-network conditions
• Real-device testing on cellular, not just Wi-Fi
• Feature flags for timeout tuning in production
• Server-side monitoring of connection failure rates by region/ISP

Connectivity is a multi-layer problem. Diagnosis requires the ladder; fixes require robustness at every layer.