Turning on the Shadowrocket connection switch enables the system network tunnel; it does not confirm that the server, DNS, or destination website is reachable. This guide is for users who already have their own provider and subscription, have imported their configuration, and still can’t connect. Work through the checks in this order: basic network → server → Global Routing → DNS → Rule. Change one setting at a time to isolate the problem, then restore the original configuration. Don’t leave temporary test settings in place.
Before you begin: Keep test conditions consistent and check your basic network
First, determine whether no webpages load or just one domain fails. If nothing loads, check your basic network and server first. If only one domain fails, the issue may also involve the website, DNS resolution, or a matching rule. Don’t rely on the system VPN indicator to confirm that your network is working, and don’t assume one successful latency test means every request will succeed.
-
Record the current settings
In Home, note the selected server and Global Routing mode. Then open Config and note the active configuration file. Keep a copy of the original configuration, and record the failing domain, time of failure, and whether you were on Wi-Fi or cellular. Before sharing your notes, hide passwords, subscription URLs, and other credentials.
-
Pause automatic connections
Go to Settings → On Demand, note the current settings, and temporarily turn off On Demand. Then switch off the connection toggle in Home. This prevents network changes from triggering a tunnel connection while you test your basic network.
-
Test your basic network
With the connection off, open a webpage you can normally access directly. If it still fails, complete any Wi-Fi sign-in, check cellular data permissions, or try another network first. Don’t start by changing Rule or DNS settings.
-
Keep the test request consistent
Once your basic network is working, reconnect and use the same full webpage URL for each test. Record whether you see a DNS resolution error, connection timeout, or certificate error—not just “page won’t load.” Treat tests on Wi-Fi and cellular as separate runs.
If a site loads with the tunnel off, that only shows the direct route was available at that moment; it doesn’t confirm that the original server is working. Likewise, if a site fails when accessed directly, that alone doesn’t prove your basic network is down. Test another site you know is directly accessible for comparison.
Step 1: Check the server and connection settings in Home
In Home, confirm that the selected server is the one you intend to use. Open its edit screen and compare each setting with the details from your provider. The address, port, Type, and authentication details must all match. Port 443 does not automatically mean the settings are correct, and you can’t identify the protocol from the port alone.
- Address and port: Check for extra spaces, typos, and an incorrect port. If the server address is a domain name, it must be resolved before a connection can be established.
- Protocol and authentication: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different parameter formats. Select the corresponding Type and enter the details you have. Don’t copy fields from one protocol to another.
- TLS settings: For connections that use TLS, check the SNI, certificate name, and transport settings provided by your provider. The connection address and certificate name may differ; don’t change them to match without confirmation.
- Subscription status: If the server entry came from a subscription, update your own subscription in Home first, then check that the selected entry is still valid. Updating a subscription and enabling a configuration file in Config are separate steps; one does not replace the other.
When you run a connectivity or latency test in Home, check both the test method and the result. A successful TCP connection only shows that the address and port accepted a connection during the test. It does not fully verify authentication, TLS, forwarding, or the destination website’s response. If you have other server entries, test one of them for comparison without changing other settings.
Error: connection refused
What it means and what to do: The destination host or an intermediate device explicitly refused the connection. The port may not be listening, or the connection may have been rejected. Check the address and port, then ask your provider to confirm the endpoint is available. Changing DNS or rules won’t resolve a port refusal.
Error: i/o timeout
What it means and what to do: A network operation did not finish within the allotted time. The delay may occur during DNS resolution, connection setup, or a later read or write. Use the nearby address and operation in the error to identify where it occurred, then test the same entry on another network. A timeout alone does not prove the password is wrong.
Error: no such host
What it means and what to do: DNS resolution did not return a usable result. Identify whether the error refers to the server’s domain or the destination website’s domain, then check the spelling and DNS settings. Don’t change the server and configuration file at the same time before identifying the domain in the error.
These are examples of errors that may appear in network logs; the wording can vary between interfaces. Keep the full error and its context when troubleshooting. A single “timeout” can make a failed server connection look like a slow website response.
Step 2: Use Global Routing to compare Proxy, Direct, Config, and Scene
In Home → Global Routing, check the current mode. Even with the right server selected, requests can fail if they don’t take the expected route. For testing, keep the server fixed and compare modes one at a time. Don’t change the server, DNS, and configuration file all at once.
| Mode | How to interpret it during troubleshooting | What to check |
|---|---|---|
Proxy | Use proxy routing as a comparison to reduce the effect of Rule-based routing. | The selected server, connection settings, and destination response. This does not mean that all other settings have been cleared. |
Direct | Use the direct access route as a comparison; requests are not forwarded through a proxy server. | Whether the local network can reach the test destination. This is not exactly the same as turning off the system tunnel. |
Config | Routes requests according to the rules in the active configuration file. | The file enabled in Config, Rule order, and the policy applied when a rule matches. |
Scene | Changes routing behavior according to the configured scene conditions. | The scene settings for the current network. For troubleshooting, temporarily use a fixed, explicit mode. |
Takeaway: Change one variable per request
With the same server selected, if Proxy works but Config fails, check the active configuration’s rules and policies next. If both fail, continue checking the server and DNS. This helps narrow down the issue; it is not a definitive diagnosis.
If Direct works but Proxy fails, that alone doesn’t prove the server is down. DNS resolution, authentication, TLS, or restrictions on the destination website along the proxy route may affect the result. After testing, restore the original Global Routing mode. If you use Scene, restore its conditions too, so a later network change won’t produce a different result.
Step 3: Use DNS to distinguish server resolution from website resolution
DNS issues can occur in two places: when resolving the server’s domain, or when resolving the destination website’s domain. A failure in the first step can prevent the proxy connection from being established. A failure in the second may leave server tests working while webpages fail to load. Read the domain in the error before deciding what to change.
- In Config, open the editor for the currently active file and check
dns-serverunder[General]. Note the original value. Make sure you’re not editing an inactive copy with the same name. - If the original configuration uses a custom DNS server, check its address, format, and reachability on your current network. With DNS over HTTPS, also check whether the HTTPS endpoint is reachable and whether its domain resolves and its certificate is valid.
- For comparison, temporarily switch to system DNS in a copy of the configuration, save and enable that copy, then reconnect. Change DNS only; leave the server and Global Routing settings unchanged.
- Try the same domain again. If it works better, investigate the original DNS route. If nothing changes, restore the original value and check the rules. Don’t keep piling on unverified changes.
[General]
dns-server = system[General] is the general settings section of a configuration file. dns-server = system sets this option to use system DNS. This snippet is for comparison testing, not a complete configuration file; don’t use it to overwrite other sections in your existing configuration. Results with system DNS still depend on the resolver provided by your current network.
DNS over HTTPS sends DNS requests over HTTPS, but it isn’t guaranteed to be reachable on every network. The DNS endpoint, server address, and destination website are separate things. Switching to another DNS transport won’t fix a server port refusal or incorrect authentication settings.
Step 4: Check Rule order and the applied policy in Config
Return to Config and confirm which file was active during the test. In Global Routing’s Config mode, rules are usually evaluated in order; a request that matches an earlier rule won’t continue to a later rule of the same type for an override. First check the rule for the destination domain, then IP rules and the final policy. Seeing “PROXY” in the configuration doesn’t mean the request matched it.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY[Rule]: Starts the rules section. This snippet illustrates the syntax only.example.comis a sample domain, not a connectivity test address or a routing recommendation for every user.DOMAIN-SUFFIX,example.com,PROXY: Matchesexample.comand its subdomains, and applies thePROXYpolicy. It matches the request’s domain suffix, not a word in the webpage path.IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Matches the IPv4 range and appliesDIRECT.no-resolvemeans the rule won’t actively trigger DNS resolution for a match; it does not disable DNS globally.GEOIP,CN,DIRECT: Matches using a country code in the IP geolocation database and routes directly. It uses IP data, not webpage language, domain suffix, or provider name. Database results may not reflect the actual hosting location.FINAL,PROXY: AppliesPROXYwhen none of the preceding rules match. The final policy does not override a matchedDIRECTorREJECTrule.
If a destination works with Proxy but fails with Config, check whether an earlier DIRECT or REJECT rule matched, and whether a custom policy group has a usable member selected. To test temporarily, add a DOMAIN or DOMAIN-SUFFIX rule for a single destination in a copy, above any potentially conflicting rules. Don’t delete the entire Rule section just to test one domain.
Takeaway: Verify the match, not just the rule’s presence
Save and enable the modified configuration, send the same request again, then use the app’s connection records or logs to check the destination and policy. A rule test is complete only when the active file is enabled, the request matches the expected rule, and the corresponding policy is available.
Wrap up: Narrow down the issue and restore your settings
The purpose of these four checks isn’t to change every setting; it’s to get repeatable comparison results. Record which test succeeded or failed, and keep the conditions consistent for your next run. If only one website fails, check whether that site is available; a single-site issue does not mean all proxy connections are failing.
| Test result | What to check next |
|---|---|
| A known directly accessible webpage still fails with the connection off | First check Wi-Fi sign-in, cellular data permissions, and your basic network. |
| The same entry fails on Wi-Fi but works on cellular | Check DNS, port, and transport reachability on Wi-Fi, and keep the error records from both tests. |
| Proxy works, but Config fails | Check the active file, rule order, matched policy, and policy group members. |
| The result changes only after changing dns-server | Retest the original DNS server’s reachability and resolution results to rule out a temporary network issue. |
| The same destination fails in every mode | Check the destination service, DNS results, and certificate errors. Don’t keep changing global settings blindly. |
- Restore the original Global Routing, DNS, and Settings → On Demand settings. Remove temporary test rules, or keep a clearly labeled copy of the configuration.
- When contacting your provider, include the protocol, server address and port, network type, time of failure, and redacted error details. Don’t send your full password or subscription credentials.
- After updating a subscription, check the currently selected entry again. After editing a configuration file, confirm which file is enabled in Config so your notes match what’s actually in use.
Shadowrocket is a paid client for Apple platforms, primarily used on iPhone and iPad. The App Store is the only place to get it. Check the App Store listing for system requirements, device compatibility, and whether the purchase is universal. Buying the client and obtaining network service are separate matters; this site does not provide, sell, or recommend nodes or subscriptions.