Fix ChatGPT Not Working With Shadowrocket on iPhone

At a glance

This guide is for iPhone users whose ChatGPT app or website will not load while Shadowrocket is connected. Check the basic network first, then inspect the active routing mode, the rule applied to ChatGPT requests, DNS resolution, and the selected connection. Compare Wi-Fi with cellular data and change one setting at a time. This helps separate a local rule or DNS problem from a connection that the destination service does not accept. The steps assume you already have your own valid subscription; obtain subscription details from your service provider.

1. Identify where the ChatGPT request fails

“ChatGPT does not work” can describe several different failures: the app may stay on its opening screen, a sign-in page may loop, a conversation may load without sending, or a response may stop midway. These symptoms do not all point to the same cause. A working connection indicator in Shadowrocket means the system VPN tunnel is enabled; it does not prove that a particular request reached its destination, used the intended rule, or received an acceptable response.

Start by noting what you can reproduce. Record whether the failure happens in the ChatGPT app, in Safari, or in both; whether it occurs on Wi-Fi, cellular data, or both; and whether other websites load. Also note the selected entry and the current option under Home → Global Routing. These details provide a baseline. If you change the node, DNS, and routing mode together, a successful retry will not show which change mattered.

iPhone network VPN tunnel Routing rule DNS resolution Service response

Use the sequence above as a fault-isolation model, not as a promise that every request follows an identical visible path. A failure before the tunnel is established calls for a different check from a request that reaches a service but receives an error. For example, if other sites also fail, first investigate the local network or selected connection. If other sites work and only ChatGPT fails, focus on the request’s rule, DNS result, and destination response.

4 modes

Global Routing options to identify: Config, Proxy, Direct, and Scene

2 networks

Compare the same test on Wi-Fi and cellular data

1 change

Adjust one variable per test so the result stays interpretable

Before troubleshooting Shadowrocket, check that the iPhone’s date and time are correct and that the base network is usable. Turn off the connection in Home briefly and try a site you normally use. If that site also fails, complete any Wi-Fi sign-in page, check cellular availability, or resolve the underlying network issue before testing ChatGPT through the tunnel. If the base network works but ChatGPT fails only while connected, continue with the routing checks below.

2. Check routing, DNS, and the selected connection

When Global Routing is set to Direct, requests can bypass the proxy. When it is set to Proxy, traffic is sent through the proxy selection rather than being decided by the configuration’s ordinary rules. Config uses the active configuration, so a rule can send a particular request to DIRECT, PROXY, or another policy. Scene may apply a separate set of conditions. Check the mode that is actually active rather than assuming the visible rule list determines every request.

If the active mode is Config, inspect the request or log view while reproducing the problem, if available in your current setup. Look for the ChatGPT-related request and note the matched rule and policy. Do not assume a single hostname covers every function: the app may make separate requests for sign-in, conversation data, or other resources. The practical question is whether the requests associated with the failure are resolving and taking the route you intend.

Routing checks

Global Routing: Note whether the active choice is Config, Proxy, Direct, or Scene.
Matched policy: In Config, check whether the relevant request matches PROXY or DIRECT.
Policy group: If the rule uses a group, verify which existing entry the group selects.
Rule position: In a custom rule list, an earlier matching rule can take effect before a later one.

Make a note of the original mode and rule before testing a temporary change.

DNS and connection checks

DNS result: Check whether the request resolves, rather than assuming every failure is a rule issue.
Selected entry: Confirm the intended existing entry is selected in Home.
Network path: Repeat the same test on Wi-Fi and cellular data.
Service response: Distinguish a resolution or connection error from an HTTP response such as 403.

Do not publish logs that reveal account details, tokens, or subscription credentials.

A DNS failure can prevent a request from reaching the stage where a routing policy or service response is useful to diagnose. If the log shows that a name could not be resolved, check the DNS settings in the active configuration and whether the chosen resolver is reachable through the current network path. Avoid copying an arbitrary resolver from an unrelated example. If DNS works for other sites but not for ChatGPT-related requests, compare the result on the other network and keep the original configuration available before changing resolver settings.

A request that reaches the destination but receives an error is different from a DNS failure. A response such as 403 can indicate that the request was rejected, but the status alone does not identify why. The selected connection’s address or reputation, service-side restrictions, account state, or a temporary service issue may be involved. Do not treat a successful latency test as proof that ChatGPT will accept that connection: a latency check and an application request test different parts of the path.

3. Run a controlled iPhone test

Use a short, repeatable test before editing a large configuration or removing entries. Keep the ChatGPT app or Safari page, destination action, and network consistent during each comparison. If you need to use a temporary routing mode to isolate a rule, write down the original setting first and restore it afterward. The goal is to discover where behavior changes, not to leave a broad test setting in place indefinitely.

Verify the base network

Turn off the Shadowrocket connection in Home. Open a familiar website on the same Wi-Fi or cellular connection. If it does not load, address the local network first; a proxy-rule change cannot fix a network that has no usable internet access.
Record the current setup

In Home, note the selected existing entry and the current Global Routing choice. If using Config, note the active configuration and any relevant custom rule. Keep credentials and subscription URLs out of screenshots and shared notes.
Reproduce one failure

Reconnect, open either the ChatGPT app or Safari, and repeat one specific action—for example, opening a conversation or sending a short message. Avoid switching between app and browser during the same attempt. Check the request or log view immediately afterward for the matched policy, DNS result, and any reported error.
Compare the network

Keep the selected entry and routing mode unchanged, switch from Wi-Fi to cellular data or the reverse, and repeat the same action. If the result changes, the network path or its DNS behavior is relevant. If it does not, continue checking the matched rule, selected entry, and service response.
Test one adjustment

If the log points to a DIRECT match, make a narrow, reversible rule adjustment or temporarily use an appropriate routing mode to test whether the request path is the cause. If the log instead points to DNS or a rejected response, address that finding rather than rearranging unrelated rules. Retest once, then restore any temporary setting that did not solve the issue.

When the active configuration is managed by your subscription, avoid editing its contents without first understanding whether a refresh may replace your changes. If a rule adjustment is needed, preserve a copy of the original configuration and keep the test narrowly scoped to the requests shown in the log. Do not add a broad rule that sends all traffic through a different route simply because one ChatGPT request failed; that can change unrelated apps’ behavior and make the result harder to interpret.

Repeat a useful test more than once if the failure is intermittent. A single successful page load may reflect a temporary network change, cached content, or a service response that did not require the same request as a new conversation. Note the time, network, selected entry, routing mode, and result. This small record is more useful than repeatedly changing settings from memory.

4. Interpret common errors without guessing

Error wording can vary by request and by the point where the failure occurs. Treat the examples below as clues to investigate, not as proof of one particular cause. If the text differs, capture the relevant line privately and compare what it says about DNS, connection establishment, or the destination response. Do not share a complete log if it contains personal data or connection credentials.

Example: DNS lookup failed

Possible cause and next step: The hostname was not resolved on the path used for this request. Check the active DNS configuration and compare the same request on Wi-Fi and cellular data. Avoid changing routing rules until name resolution succeeds.

Example: Connection timed out

Possible cause and next step: A connection attempt did not complete in time; this does not by itself prove that the account or password is wrong. Confirm the selected entry, test the other network, and check whether other destinations work through the same route.

Example: HTTP 403

Possible cause and next step: The destination returned a rejection response, which is not the same as a DNS lookup failure. Check whether the account works outside the affected route and whether the service reports an account or access issue. If the rejection occurs only with one existing entry, ask your service provider to review that connection.

Example: TLS or handshake error

Possible cause and next step: The encrypted connection did not complete as expected. Check that the iPhone date and time are correct, verify the selected entry’s supplied settings, and compare networks. Do not substitute guessed server parameters for the values provided with your own service.

If only the ChatGPT app fails but Safari works, the difference may be app-specific behavior, a cached session, or a different set of requests. If both fail in the same way, a shared routing, DNS, network, or service-side cause becomes more plausible. Close and reopen the affected app once after recording the original result, then test again without changing several Shadowrocket settings at the same time.

If ChatGPT also fails when Shadowrocket is disconnected and the base network works, check the service’s own availability and your account or sign-in state. A client-side routing change cannot resolve an account restriction or a temporary issue at the destination. Likewise, if the same request fails on both Wi-Fi and cellular through the same selected entry, that result is useful evidence to share with your service provider, with sensitive values removed.

FAQ

Use these answers to decide which check to repeat. Keep the original routing choice and configuration available so that troubleshooting remains reversible.

ChatGPT opens, but messages will not send. What should I check first?

Keep the current entry selected, reproduce one send attempt, and inspect the request or log view. Check whether the request resolved, which policy matched, and whether the destination returned an error. A page opening does not prove that the separate request used to send a message followed the same path.

Should I switch Global Routing to Proxy?

Only use it as a temporary diagnostic if you understand the effect and note the original mode first. If ChatGPT works in Proxy but not in Config, inspect the matching rule in the active configuration. Restore the original mode after the comparison; a global test setting can change routing for other apps.

Why does a low latency result not fix ChatGPT?

A latency test measures reachability to its test target; it does not verify every DNS lookup, rule match, application request, account state, or service response. Check the actual failed request in the log and compare its result with the latency test rather than treating the latency value as an end-to-end test.

What should I send my service provider if the issue remains?

Share the time of the test, whether you used Wi-Fi or cellular, the selected entry’s label, the routing mode, and the relevant error text. Remove subscription URLs, tokens, private addresses, account details, and unrelated log entries. Ask the provider to review the existing connection; do not send private credentials in a public post.