Turning on the Shadowrocket connection only confirms the local connection state; it does not prove that the remote server, DNS resolution, or destination website is working. This guide is for users who already have their own service details and subscription but can't load webpages. Start by checking the underlying network, then narrow down the issue by testing the server, routing mode, DNS, and rules one at a time. Restore your usual settings when you're done.
1. Separate basic network issues from proxy connection issues
Don't delete your subscription or reset all settings straight away. First, note the server selected in Home, the Global Routing mode, and the configuration file currently in use in Config. The same “webpage won't load” symptom can have several causes. Keeping track of your starting settings helps identify which change actually fixed the problem.
A connected status usually means the local VPN tunnel has started. You still need to check whether the remote server accepts connections, the authentication details are valid, and DNS responds. Test with an ordinary webpage you can normally access without signing in, and note the exact time and error.
-
Record the current settings
Note the selected server and Global Routing mode in Home, and the active configuration in Config. Save the original settings before making changes so you can distinguish the initial issue from anything introduced during testing.
-
Turn off the connection
Turn off the connection switch in Home. If it reconnects automatically, check Settings → On Demand, temporarily disable the trigger, then make sure the connection is off.
-
Test a direct connection
Open a webpage known to work without a proxy in Safari. If it still won't load, check Wi-Fi sign-in requirements, cellular data access, and the underlying network first. Don't start by changing rules.
-
Reconnect and retest
Turn the connection back on and test the same webpage again. Keep the network, server, and destination the same, and change only one setting per test.
-
Compare networks
If possible, switch between Wi-Fi and cellular data and test the same destination. If it fails on only one network, check that network's DNS resolution, port access, or transport restrictions first.
2. Check the server address, port, and protocol settings
In Home, confirm which server is actually selected; don't rely on the subscription group name. Open the server's edit screen and compare Address, Port, Type, and authentication fields with your own service details. A successful subscription update only confirms that its contents could be retrieved and parsed—it doesn't prove that every server in the list is currently reachable.
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different settings. Check the fields for the protocol the server actually uses. For TLS, verify the server name and certificate requirements; for transport settings, check parameters such as the path and hostname. Don't try to fix the issue by changing Type at random.
- Address and port: Port must match the listening port on the remote server. Even if one service uses 443, that doesn't mean every server should be changed to 443.
- Authentication details: Check that the password, UUID, or key comes from the current valid configuration, and make sure copying it hasn't added spaces or line breaks.
- Time and certificates: An incorrect device clock can interfere with TLS verification. Set the clock correctly first. If you see a certificate error, check the name and server configuration rather than disabling verification.
- What the test tells you: Run Connectivity Test in Home and note which test method it uses. A successful TCP connection doesn't confirm protocol authentication, and a single latency reading doesn't prove that webpages will load.
If the connection log contains any of the messages below, use the stage where it appears to guide your investigation. Different protocols and error sources may add prefixes or other details. Keep the full log rather than drawing conclusions from one word.
Error: connection refused
Cause: The destination or an intermediary rejected the connection. Common causes include a mismatched port or a service that isn't listening.
Fix: Check Address and Port, then ask your service provider whether the port is currently listening.
Error: i/o timeout
Cause: A network read or write didn't complete in time. This alone doesn't tell you whether traffic was dropped, the server failed to respond, or a later handshake stalled.
Fix: Note the destination and stage where the timeout occurred. Keep the configuration unchanged, switch networks, and test again. Then compare with another server you already have in the same subscription.
Error: no such host
Cause: The lookup didn't return a usable host address. The server hostname may be incorrect, or there may be an issue with the DNS path.
Fix: Check the domain in the error first. If it's the server address, resolve that issue before testing webpage domains.
3. Use Global Routing to narrow down the issue
Go to Home → Global Routing and confirm the current mode. Direct, Proxy, Config, and Scene are different ways of handling traffic—not four levels of connection quality. Note the original mode before switching temporarily, and restore it when you're done.
| Mode | What it does | How it helps troubleshoot |
|---|---|---|
Direct | Routes traffic directly | Checks the basic direct connection; it can't verify whether the proxy server works. |
Proxy | Routes traffic through the proxy | Temporarily tests the current proxy route, reducing the effect of rules in the configuration. |
Config | Applies rules from the active configuration file | Useful for checking rule order, policy names, and the final fallback. |
Scene | Applies settings based on configured conditions | Check which scene the current network triggers and which settings that scene actually uses. |
Compare the same server and URL in each mode. If Proxy works but Config doesn't, check the rules and policies first. Keep in mind that switching modes can also change the request path and DNS behavior. If Proxy fails too, revisit the server settings and DNS rather than repeatedly adding domain rules.
Bottom line: Fix the route before changing rules
Prioritize rule troubleshooting only when the same destination works through a fixed proxy route but consistently fails in Config. If both modes fail, leave the rules as they are and check the server and DNS path they share.
4. Check DNS: identify which domain fails to resolve
DNS issues can occur at two points: the remote server's hostname must resolve to establish a connection, and the webpage's domain must resolve when you visit it. A failure at the first point can prevent the proxy route from being established; a failure at the second may leave the connection on while the webpage keeps loading. Checking the actual domain in the error is more useful than repeatedly changing DNS servers.
Check the app's DNS settings in Settings → DNS, and see whether the active Config file contains DNS settings too. Note the current values and where they come from. Changing Settings alone may not be enough if the active configuration specifies other DNS behavior. Check request logs to understand which settings are taking effect.
- Check the format first: An IP address and an encrypted DNS URL are different types of input. Use the format supported by the setting; don't just remove the protocol prefix and keep using the rest.
- Then check reachability: Encrypted DNS still needs a working network connection. If the resolver endpoint is a hostname, that hostname may need to be resolved first. Switching to an encrypted method doesn't automatically fix network issues.
- Check IPv4 and IPv6 results: A domain may return both A and AAAA records, but IPv4 and IPv6 can have different levels of reachability. If the logs show failures concentrated on one address family, check that path rather than assuming the entire domain is down.
- Avoid misleading tests: Don't replace an HTTPS website's domain with its IP address and use a certificate error to diagnose DNS. HTTPS also depends on the certificate name, SNI, and virtual hosting. A failed request to an IP address doesn't, by itself, prove a DNS problem.
5. Check rule order, policies, and FINAL
In Config, confirm which configuration file is active, then inspect its rules. Rules are generally matched in order, so an earlier match can determine whether later rules ever handle a request. Adding a domain rule at the end of the file may have no effect if an earlier rule already captures that traffic.
The snippets below are for recognizing syntax only; they aren't a general-purpose replacement for your current configuration. example.com is an example domain, and 192.0.2.0/24 is a documentation-only network range. For real troubleshooting, use the domain that actually fails, request logs, and your own policies.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX: Matches the specified domain suffix and its subdomains. Check for an incorrectly added protocol, path, or typo. A rule's domain isn't a complete webpage URL.IP-CIDR: Matches a destination IP range. In the example,no-resolveprevents this address rule from triggering a DNS lookup just to match it; it does not disable all DNS.GEOIP: Matches based on the IP geolocation database, not a website's display language or domain suffix. Database classifications don't always reflect where a service actually operates.FINAL: Provides a fallback policy for requests that didn't match earlier rules and should be placed at the end. It points to Direct, Proxy, or another valid policy, determining where unmatched traffic goes.
If the configuration references a custom policy group, check the selection currently active within that group too. A rule matching a group name doesn't guarantee that traffic will use a proxy—the group may be set to direct traffic or to a server that's currently unavailable. Use request logs to trace “destination domain → matched rule → policy group → actual route”; this is more reliable than checking rule text alone.
6. Common questions and wrapping up
Why is latency shown if webpages still won't load?
First, confirm which test method Connectivity Test uses. A TCP connection or response from a test address covers only part of the route. Retest the site that actually fails and check authentication, DNS, and rule matches. A latency reading does not prove that every website is reachable.
If only one website won't load, should I re-import the subscription?
Test other webpages through the same server, then check the failing site's request domain and policy. If Proxy works but Config fails, check the rules for that domain and its related resources first. Re-importing a subscription usually won't fix a domain-routing mistake in the configuration file.
How can I test a direct connection if it turns back on after I disconnect?
Go to Settings → On Demand and temporarily disable the relevant trigger. Then return to Home, turn off the connection, and check its status. Restore the original setting after testing so an On Demand reconnect isn't mistaken for a failed manual switch.
Why does the original server still fail after the subscription updates?
An update refreshes the list; it doesn't guarantee that every server works. In Home, check which entry is actually selected and whether its address, port, or authentication details have changed. If the list doesn't match your valid service details, check with your existing service provider. Re-importing the same link repeatedly can create duplicate entries without fixing anything.
Once the connection works again, undo temporary changes made for testing: restore your usual Global Routing mode, confirm the correct file is selected in Config, and reinstate any On Demand conditions you need. Then retest a direct webpage, a webpage that should use the proxy, and the specific feature that failed. Checking only the homepage may miss sign-in or image requests.
- Keep a concise record: Time of failure, network type, server protocol, Global Routing mode, failed domain, and full error message.
- Note what worked: For example, “Same server: Proxy works, Config fails,” rather than the vague “It worked after reconnecting.”
- Remove sensitive details: Before sharing logs, remove the full subscription URL, token, password, UUID, and keys. Keep only the error stage and rule details needed to diagnose the issue.