If Claude will not load on your iPhone while Shadowrocket is enabled, check the connection itself before changing rules. This guide assumes you already have your own subscription and a connection that you are permitted to use. You’ll compare Wi-Fi with cellular data, verify Shadowrocket’s Global Routing mode, check whether the active rules send Claude’s traffic to the intended outbound policy, and then investigate DNS, the selected connection, and possible IP-related restrictions. Change one thing at a time so the result points to a cause rather than adding more variables.
1. Start with a controlled test on iPhone
“Claude does not work” can describe several different problems: the app may remain on its loading screen, sign-in may fail, a conversation may not send, or responses may stop partway through. A webpage that works in Safari does not necessarily prove the Claude app can reach its service. The app and browser may use different existing connections, cached sessions, or request patterns. Record the exact symptom and whether it happens in the app, in Safari, or in both.
First check whether the issue is tied to Shadowrocket or to the current network. On iPhone, note whether you are using Wi-Fi or cellular data, then test Claude with Shadowrocket off and on. When you turn it off, iOS may ask you to confirm the VPN state. Do not change the selected connection, configuration file, DNS settings, and routing mode all at once: if Claude starts working, you will not know which change mattered.
Use the same Claude screen and the same action for each comparison. For example, try opening a fresh conversation or reloading the same page, rather than comparing a cached page on one attempt with a new sign-in on another. If a request fails, note the approximate time and whether other ordinary websites load. This helps distinguish a general tunnel problem from a destination-specific failure.
Wi-Fi and cellular are useful comparison conditions, not interchangeable versions of the same connection. A Wi-Fi network may have its own DNS settings, filtering, or captive sign-in page; cellular data uses a different network path. If Claude works on one and fails on the other with the same Shadowrocket settings, focus on that network path before replacing the whole configuration.
- On Wi-Fi, confirm that the iPhone has completed any network sign-in page and that other secure sites load.
- On cellular, confirm that cellular data is enabled for the Claude app in iOS Settings and that the signal is stable.
- Repeat the same Claude action with Shadowrocket off, then on, without switching networks between those two attempts.
- Write down the result for each condition: app or browser, Wi-Fi or cellular, Shadowrocket state, and whether the request loaded.
If Claude fails both with Shadowrocket off and on, the proxy is not yet the only likely cause. Check the current service status and account access through Claude’s official channels, and confirm that the service is available for your location and account. A proxy configuration cannot resolve an account restriction, service outage, or policy-based unavailability. Do not use routing changes to evade those limitations.
2. Check Global Routing and the active rules
In Shadowrocket, open Home and read the current Global Routing selection. The four labels—Proxy, Direct, Config, and Scene—describe different routing behavior. With Proxy selected, traffic handled by Shadowrocket is sent through the selected connection. With Direct selected, it is not sent through that proxy. Config follows the rules in the active configuration, while Scene applies the selected scene’s behavior. A visible VPN indicator only shows that a tunnel is active; it does not prove that Claude’s requests are being routed through a proxy.
Rules in the active configuration decide whether matching traffic uses PROXY or DIRECT. This is the usual place to investigate when only Claude fails while other destinations work.
Suitable for: everyday rule-based routing and targeted diagnosis
Traffic handled by Shadowrocket uses the currently selected connection rather than relying on a destination-specific rule to choose DIRECT or PROXY.
Suitable for: a brief diagnostic comparison when permitted
Traffic goes directly rather than through the selected proxy. This can help determine whether the issue appears only when the proxy path is involved.
Suitable for: checking the direct network path where service access is available
For a rule-based setup, open Config and confirm which configuration is selected. In its rules, look for entries that may match Claude’s hostname or a broader domain category. Check the policy at the end of each matching line: a matching rule can send a request to PROXY, DIRECT, or another policy. Rule order matters because a more general rule placed earlier can affect traffic before a later, narrower rule is reached. Do not assume that an app name or server label determines the route.
Use the domain shown by the failed request, if available, rather than guessing a single hostname. A service can use different hostnames for its website, authentication, API requests, and supporting content. A rule that routes one hostname correctly may not cover every request needed to sign in or send a message. Avoid adding broad rules based only on an unverified list; use the request information available in Shadowrocket and make a narrow, reversible change only when you understand what it matches.
When you have a legitimate reason to compare routing behavior, change Global Routing briefly, repeat one test, then restore your normal setting. If Claude loads with Proxy but not with Config, the difference points toward the active rules, the selected configuration, or the policy assigned to a matching rule. If both modes fail in the same way, investigate the connection, DNS, the network, or service availability instead of repeatedly editing rules.
- In Home, confirm the selected connection and the current Global Routing mode.
- In Config, verify that the intended configuration is active, not merely imported.
- Check the rules and policies relevant to the failed hostname; note whether they select PROXY or DIRECT.
- After a rule change, start a new request in Claude. An already-open connection may continue using its previous route.
3. Verify the connection, DNS, and possible IP issues
A selected connection is not necessarily a working connection. In Home, make sure the intended entry is selected and the connection switch is on. If Shadowrocket shows a connection test option, use Home → Connectivity Test and note whether the test completes or times out. A connectivity test can help assess the connection to its test destination; it does not guarantee that Claude’s service is reachable, that the selected rules match Claude, or that the service accepts the resulting IP address.
If the test fails, first check whether the configuration details are still current and whether your own subscription has refreshed successfully. A recently changed or unavailable connection can leave an entry visible even though it no longer works. If your subscription provider has announced a change, follow its instructions and then test again. Do not paste private subscription URLs, authentication values, or account details into a public report or diagnostic message.
DNS is another possible cause. A DNS problem may prevent a hostname from resolving, return a result that cannot be reached on the current network, or affect only certain destinations. Do not change DNS merely because Claude is slow. First compare whether other domains resolve and load under the same conditions. If Shadowrocket exposes DNS options in your current configuration, record the existing setting before changing it. Change one DNS setting at a time, retry the same Claude action, and restore the original value if there is no clear improvement.
Symptom: Claude stays on “Loading”
Possible cause and next step: The app may not be completing a request, or the current Wi-Fi or cellular path may be unstable. Retry once on the same network with Shadowrocket off, then on. If only the enabled test fails, check the selected connection and Global Routing before changing DNS.
Symptom: “Network error” or a request timeout
Possible cause and next step: The connection, destination route, DNS lookup, or service response may be failing; the exact wording can vary. Check Home → Connectivity Test, then compare Wi-Fi with cellular. If other destinations work, inspect the rules that match Claude’s request rather than assuming the whole tunnel is down.
Symptom: Sign-in completes, but messages will not send
Possible cause and next step: Sign-in and conversation requests may use different destinations or longer-lived connections. Reopen Claude and start a new request, then inspect the relevant request records and matching rule if available. Also confirm that the service is available to your account and location.
The node’s exit IP can also matter. A service may reject, challenge, or limit an IP because of its reputation, location, traffic pattern, or its own access controls. A successful Shadowrocket connectivity test does not certify an exit IP for Claude. If the same configuration works for other sites but Claude consistently rejects its requests, compare the behavior on the direct network where service access is permitted, and consult the provider of your own connection about the connection’s status. Do not assume that repeated switching will overcome an account or regional restriction.
When comparing two of your existing connections, keep the network, routing mode, Claude action, and test time as consistent as possible. Select one connection in Home, establish a fresh request, record the result, and then repeat with the other. A single success or failure can be temporary, so note whether the result repeats. Do not change DNS and the selected connection during the same comparison.
Diagnosis: separate reachability from service acceptance
If Home → Connectivity Test succeeds but Claude fails, the tunnel is not necessarily the problem. Check the matching rule and destination behavior, then consider DNS or the service’s response to the exit IP. If Claude also fails with Shadowrocket off, investigate the ordinary network, account, and service availability before editing the proxy configuration.
4. Isolate the cause without disrupting other traffic
Use this sequence when the first comparison does not identify the cause. It keeps the baseline clear and limits changes to the smallest relevant part of the setup. Before editing a configuration, preserve the original settings or make a copy where the interface allows it. The exact controls can vary by app version, so follow the labels displayed on your iPhone rather than relying on an assumed button position.
- Record the baseline. Note Wi-Fi or cellular, the selected connection, Global Routing, the active configuration, and the exact Claude symptom. Also check whether another ordinary site loads.
- Test the network without the tunnel. Turn Shadowrocket off briefly and repeat the same Claude action, provided the service is available on that direct network. Turn the connection back on after the comparison.
- Verify the tunnel. In Home, select an existing connection and confirm its status. Run Home → Connectivity Test if available. A failure here points toward the connection or network before it points toward Claude-specific rules.
- Inspect routing. Check Global Routing and, when using Config, verify the active file and the policy for the request’s matching rule. Do not switch to a different configuration as part of the same test.
- Compare the other network. Repeat the controlled test on cellular if the first test was on Wi-Fi, or on Wi-Fi if it began on cellular. Keep the Shadowrocket settings unchanged while switching networks.
- Test one adjustment. If the evidence points to a rule, DNS setting, or connection entry, change only that item and repeat the same request. Restore the previous value if the result is unchanged or worse.
Keep in mind that switching networks may trigger On Demand behavior or reconnect the tunnel. If the connection state changes automatically, note it before interpreting the Claude result. The purpose of this process is not to force a particular routing mode; it is to learn whether the failure follows the network, the tunnel, a rule, or the service response.
If you contact support for your own service, provide the time of the test, whether you used Wi-Fi or cellular, whether Connectivity Test succeeded, and a description of the error. Share only the minimum diagnostic information requested through an appropriate private channel. Redact account identifiers, private subscription URLs, authentication details, and any personal conversation content.
5. Frequently asked questions
Claude works in Safari but not in the app. Is Shadowrocket broken?
Not necessarily. The app and Safari can use different existing sessions and request paths. Test the Claude app with Shadowrocket off and on, then compare the same app action on Wi-Fi and cellular. If only the app fails, reopen it and start a new request; if the failure follows Shadowrocket, check the app’s matching traffic and active routing policy.
Connectivity Test succeeds. Why does Claude still time out?
The test only checks its own destination and method. Claude may match a different rule, need a hostname that is not resolving correctly, or be rejecting or limiting the connection’s exit IP. Check the relevant request and policy, then compare with another network while keeping the rest of the settings unchanged.
Should I use Proxy instead of Config?
Use Proxy only as a brief diagnostic comparison when appropriate. If Proxy works but Config fails, inspect the active configuration and the rules that match Claude. Restore your normal routing mode after the test; a temporary comparison is not a substitute for understanding which traffic is being routed.
Can I fix Claude by changing the node’s IP or DNS?
DNS may be relevant if name resolution is failing, and an exit IP may affect how a service responds, but neither is a guaranteed fix. First identify whether the problem follows the network, tunnel, or rule. Change DNS only with a recorded baseline, and ask the provider of your own connection about an unavailable or changed entry. Respect the service’s location and account restrictions.
The most useful diagnosis is the one supported by a repeatable comparison. If Claude fails only with Shadowrocket enabled, focus on the selected connection, Global Routing, matching rules, and DNS. If it fails only on one network, investigate that network’s path. If the same failure occurs with the tunnel off and on, check service availability and account access before making further configuration changes.