Shadowrocket Guide: Connected but No Internet—Check Server, Mode, DNS, and Rules

1. Identify the scope before reinstalling

First distinguish a basic network issue from one that occurs only after connecting. Turn off the connection on Home and use Safari to open two websites that normally work without a proxy. Then turn the connection on and visit the same pages. Keep the Wi-Fi or cellular network unchanged during testing. Changing the network, server, and configuration at the same time makes it difficult to identify the cause.

1. Record the original settings

   On Home, note the selected server and Global Routing mode. In Config, note the currently enabled configuration. Save a copy before editing a configuration, and do not include passwords, full subscription URLs, or other credentials in your notes.

2. Compare with the connection off

   Turn off the connection switch on Home and retry the page. If the connection turns back on automatically, check Settings → On Demand. Temporarily disable any active triggers during testing, then restore them after troubleshooting.

3. Check the basic network

   If ordinary websites still do not load with the connection off, check Wi-Fi sign-in, cellular data access, and signal strength first. For public Wi-Fi that requires authentication, complete the sign-in flow in the system prompt or Safari.

4. Keep test destinations consistent

   Choose one page that is known to work directly and one that normally requires your own server. Record whether each loads or times out. Do not use the result from a single website to represent the entire network.

If access also fails with the connection off, address the basic network first. Continue with the checks below only if the failure occurs after connecting. If just one website fails, consider a problem with the site itself, access restrictions, or differences in rule handling. A system VPN indicator does not prove that a particular remote website has connected successfully.

2. Check the server: a test result does not prove full availability

First confirm that the selected server can complete an actual request. Run Connectivity Test on Home, then check the selection in the SERVER list. A latency value usually means only that a response was received under the test conditions; it does not guarantee that all domains, ports, and app traffic will work.

• Address and port: Open the selected server's edit page and check the address and port against the details provided by your service provider. There is no universal port. Enter 443 only when it is specified in your existing parameters; it is not a default fix for every protocol.
• Authentication parameters: Check the password, UUID, or key required by the protocol in use. Parameters for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are not interchangeable.
• Transport parameters: If the server requires TLS, SNI, a path, or a particular transport, match the existing parameters. Do not disable certificate verification to hide a hostname or certificate problem.
• Service status: Ask your service provider to confirm whether your existing service is active, the server is under maintenance, or connection limits apply. Importing the same data again will not fix a remote service that has stopped.

Read error text in the context of where it occurred. The following are underlying error snippets that may appear in connection logs. Exact wording varies by protocol and failure stage; a line of text alone cannot establish whether the provider, DNS, or rules are at fault.

3. Check Global Routing: compare modes to narrow down the cause

Global Routing determines how requests are routed; it cannot fix an unavailable server. On Home → Global Routing, note the current selection, then briefly compare Proxy and Config. Restore the original selection after testing so diagnostic changes do not permanently alter the route for all requests.

On Demand controls when the connection is triggered; it does not replace Global Routing's request routing. If the connection turns on automatically after being switched off, check Settings → On Demand first. If it is on but only some websites fail, check the mode and the specific requests rather than repeatedly toggling On Demand.

4. Check DNS: distinguish the server hostname from the destination hostname

Start DNS troubleshooting by identifying which name failed to resolve. If the server address is a hostname, resolution may be required before the connection can be established. A destination website's hostname follows the resolution path used by that request. Failure in the first case prevents a server connection; failure in the second may affect only some websites.

Being able to reach a port does not guarantee that resolution is correct. Encrypted DNS also requires the resolver address to be reachable and TLS validation to succeed. A resolver addressed by hostname may itself require an initial lookup. Adding several unfamiliar resolver addresses to a configuration adds variables and does not prove that the issue has been found.

1. In Config, confirm which file is enabled and open its edit view. Check the existing dns-server setting under [General]. Save the original value first; do not overwrite the entire section.
2. If the problem started right after a manual DNS change, restore the previous working setting. For comparison, you can use dns-server = system in a copy of the configuration to test the system resolver path. This is a diagnostic baseline, not a universal final setting.
3. After saving and enabling the test configuration, reconnect and make a new web request. The browser may reuse an existing connection or cache, so a single refresh is not enough to prove the new setting took effect.
4. If there are manual hostname mappings under [Host], check whether any point to an old address. Restoring DNS settings does not automatically remove separately configured static mappings.

5. Check rules: follow the first match through FINAL

In Config mode, check the rules in the configuration that is actually enabled, not just whether a file exists. Rules are usually matched from top to bottom, so a broad rule near the top may prevent a more specific rule below it from taking effect. First confirm the enabled file in Config, then inspect entries in [Rule] related to the failed domain and the final policy.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

This code illustrates syntax; it is not a complete configuration to replace your everyday setup. example.com is an example domain, and PROXY must refer to an available proxy policy. If your file uses a named policy, check which server that policy actually selects, not just the Home list.

• DOMAIN-SUFFIX: DOMAIN-SUFFIX,example.com,PROXY matches the domain and its subdomains. A website may also request other domains, so a working homepage does not mean that images, sign-in, or API requests match the same rule.
• IP-CIDR: 192.168.0.0/16 represents a range of addresses. In the example, no-resolve avoids triggering a domain lookup solely for that IP rule; it does not mean that DNS is no longer used anywhere in the connection.
• GEOIP: GEOIP,CN,DIRECT selects a policy based on IP geolocation. It is not the same as matching a domain suffix, and the result depends on the database in use.
• FINAL: FINAL,DIRECT connects directly when none of the preceding rules match. If the destination requires an existing proxy but falls through to this rule, it may be unreachable even when the switch is on.

Change one rule at a time and retest the same destination. If Proxy mode also fails, changing FINAL to a proxy will not fix a server authentication error. If only Config mode fails, first check the matching rule and its policy. After testing, remove any temporary rules you do not need to keep.

6. Common questions and wrapping up

When wrapping up, keep a reproducible description of the issue rather than sharing a configuration file containing credentials. Record the network type, server protocol, Global Routing mode, failed destination, and failure stage; these details are usually more useful than noting that “the switch is on.” Before contacting your service provider, remove passwords, UUIDs, private keys, and subscription tokens.