Home / Notes / Layers

Fix ChatGPT Not Working on iPhone With Shadowrocket (2026)

If ChatGPT fails while Shadowrocket is enabled, the cause may be a direct routing rule, DNS interference, an unsuitable proxy node, or an iOS VPN conflict. Follow these practical checks to restore access on Wi-Fi or mobile data.

2026-08-21 Structure

Why these keep getting welded into one thing

Start with the three-layer check

When ChatGPT stops responding while Shadowrocket is enabled, the first conclusion is usually “the node is broken.” That is only one possibility. The request can be sent directly by the active config, resolved through a DNS path that does not match the tunnel, rejected by the selected exit, or interrupted by another VPN-style service on iPhone. These causes produce similar symptoms: the ChatGPT app keeps loading, the website shows a network error, login does not complete, or a conversation opens but new messages never arrive.

Shadowrocket does not provide a ChatGPT account, an AI service plan, or a guaranteed route. It applies a local policy to traffic and sends matching requests to an exit that you have already added. The subscription or server record is one layer. The active config is another. iOS VPN authorization and other network extensions form a separate system layer. If these are mixed together, changing a server may appear to fix a rule problem, while changing Global Routing may hide a DNS problem for only one network.

A useful order is to ask four questions:

  • Does ChatGPT work when Shadowrocket is completely disabled?
  • Is the expected exit actually selected under SERVER on Home?
  • Does the active Config send ChatGPT traffic to Proxy rather than DIRECT?
  • Is another VPN, DNS filter, security app, or work profile competing for iOS network control?

Test one variable at a time. Do not delete the subscription, replace every node, and change several routing modes in one attempt. A single successful test is more useful when you know exactly what changed.

Separate the symptom from the cause

Begin outside Shadowrocket. Open ChatGPT with the Shadowrocket switch off, then try the same account and the same network. If it fails in the same way, the client is not yet the main suspect. Check whether the service is temporarily unavailable, whether the account can sign in through a normal browser, and whether the iPhone has a stable connection. A local app update, an expired login session, or a service-side incident can look exactly like a proxy failure.

If ChatGPT works with Shadowrocket off but fails immediately after the switch is enabled, the difference is meaningful. It points toward routing, DNS, the selected exit, or an iOS network conflict. Record the exact behavior rather than using only “it does not work.” For example, distinguish among these cases:

Observed behavior More likely area to inspect
ChatGPT app cannot sign in, while unrelated apps also fail Selected exit, VPN authorization, DNS, or a conflicting network extension
ChatGPT website opens, but requests keep timing out Incomplete routing, unstable exit, or a blocked streaming connection
Only the ChatGPT app fails; Safari works App session, app-specific behavior, cached connection, or different domain matching
It works on Wi-Fi but not on mobile data Different DNS, carrier filtering, On Demand behavior, or a mobile-data permission issue
It works with Proxy but not with Config The active config is sending the required request to DIRECT or another unsuitable policy

This comparison is not a promise that one routing mode is always best. It is a diagnostic probe. If Proxy sends all traffic through the selected exit and ChatGPT begins working, the result suggests that the Config rules deserve inspection. It does not prove that the exit is healthy for every service, and it does not mean Proxy should remain enabled permanently.

Check SERVER and DNS before editing rules

On Home, confirm that SERVER contains a usable entry and that the intended entry is selected. A subscription can update successfully while the selected exit is offline, overloaded, or unsuitable for the request. A low latency number is not a complete quality test: it may measure only a short handshake to the server and say nothing about ChatGPT’s authentication, API, or streaming connections.

Compare two or three exits from the same source if they are available. Keep the comparison simple. Use the same network, the same browser or app, and the same test sequence. If one exit works and another does not, the problem is probably not the basic Shadowrocket installation. It may be the exit’s location, reputation, congestion, DNS behavior, or ability to maintain long-lived connections.

DNS deserves a separate check because routing the connection and resolving the hostname are related but not identical operations. A DNS setting can cause a hostname to resolve through a local or filtered resolver even when the eventual connection is sent toward Proxy. Conversely, forcing every DNS request through an unsuitable path can make ordinary sites fail and create the impression that ChatGPT itself is down.

Look for a consistent pattern:

  • If many domains fail to resolve, investigate the DNS mode and the network first.
  • If only ChatGPT-related domains fail, compare the selected exit and the matching rules.
  • If the page opens but login or message streaming fails, suspect incomplete domain coverage or an unstable exit rather than only DNS.
  • If changing from Wi-Fi to mobile data changes the result, compare the network’s DNS and any iOS-specific restrictions instead of immediately importing a new config.

Do not copy random DNS addresses from an unrelated guide and assume they are universally faster. The appropriate choice depends on the network, the rules in the active config, and whether the resolver can be reached through the same path as the request. Shadowrocket can apply the policy, but it cannot make an unreachable resolver reliable.

Run a controlled routing test

The following test is intended to identify the layer, not to serve as a permanent configuration. Before changing anything, note the current selected SERVER, active Config filename, Global Routing mode, and whether the connection is Wi-Fi or mobile data. This gives you a way back and prevents two different experiments from becoming one uncertain state.

  1. Open ChatGPT with Shadowrocket disabled and confirm whether a new conversation or message works.
  2. Enable Shadowrocket and wait for the iOS VPN indicator or connection state to settle. If iOS asks for VPN permission, accept it only for the official App Store installation you intended to use.
  3. On Home, verify the selected SERVER. Do not use an empty list, an expired record, or an entry that cannot establish a connection as the test exit.
  4. Temporarily set Global Routing to Proxy and repeat one small ChatGPT test, such as opening a conversation and sending a short message.
  5. If the test succeeds in Proxy, return to Config and inspect the policy that handles the relevant request. Look for a broad DIRECT rule, a policy group pointing to an unavailable exit, or a rule order that matches before the intended proxy rule.
  6. If it still fails in Proxy, compare another exit, then compare Wi-Fi with mobile data. If every exit fails only while Shadowrocket is active, inspect DNS and iOS network conflicts before changing the config.
  7. Restore the original Global Routing choice after the test unless you have a clear reason to use Proxy for all traffic.

Rule order matters. A later, more specific rule cannot help if an earlier broad rule has already matched the request. A config may also use a policy group rather than a single exit, so the visible node selected on Home is not necessarily the final policy used for every domain. Read the active file and its policy names as a decision tree, not as a list of server names.

When checking a rule, avoid adding large blocks copied from the internet without understanding their scope. A rule designed for another client may use different syntax, policy names, or rule-set behavior. Importing it can make unrelated services fail. If you need a broader explanation of how files and exits differ, see A config file is not a subscription. For the role of Global Routing, see How to read Global Routing.

Check iOS VPN and network conflicts

iOS permits several apps and profiles to influence network traffic, but they do not always cooperate. If you use another VPN client, a DNS filter, an ad blocker with a local VPN, a security app, a corporate management profile, or a content filter, temporarily disable the other service for a controlled test. Do not run multiple clients that each expect to own the VPN channel and then judge Shadowrocket by the combined result.

Also check whether an older VPN profile remains in iOS Settings. An old profile can reconnect through On Demand after you think it is off, or a security application can recreate its local tunnel in the background. The exact settings names can vary by iOS release, but the principle is stable: one test should have one active traffic owner. If the conflict disappears after removing or disabling the competing profile, the issue is system-level rather than a missing ChatGPT rule.

Mobile data adds another group of variables. Confirm that Shadowrocket and ChatGPT are allowed to use mobile data, and test with Wi-Fi Assist or similar automatic network switching in mind. A connection can move between Wi-Fi and cellular while a long response is streaming. That interruption may look like a failed proxy even though the original route was valid.

Do not repeatedly reinstall Shadowrocket as a first response. Reinstallation does not repair a bad exit, a wrong Config, or an iOS conflict, and it may remove useful local information. First record what works with the switch off, what works in Proxy, and what changes between Wi-Fi and mobile data. Reinstall only when there is a separate, reproducible installation problem.

Avoid common false fixes

Buying or importing another subscription is not a universal repair. A new list may contain the same routing assumptions, the same DNS path, or the same type of unsuitable exit. It also makes the diagnosis harder because the test now changes both the second layer and the selected entry.

Switching Global Routing back and forth can also create a misleading success. Proxy may work because it bypasses a DIRECT rule, but it sends much more traffic through the exit than necessary. That can increase latency, consume data, expose services that should remain local to the proxy, and make the exit reach its limits sooner. Once the cause is known, fix the narrow rule or policy rather than leaving every request in Proxy.

Clearing the ChatGPT app session can help when only the app has a stale login state, but it will not fix a connection that fails in Safari as well. Likewise, changing the iPhone’s system DNS may affect ordinary resolution without correcting Shadowrocket’s active policy. Treat each action as a test with a specific hypothesis.

Finally, avoid unofficial installers, modified IPA files, enterprise signatures, and “unlocked” packages. Shadowrocket is an App Store purchase for iOS, iPadOS, and Apple Silicon Mac, and this site does not provide nodes, subscriptions, invitation codes, or IPA files. The official source keeps the installation and update path identifiable. If you need the product itself, use the official download guide.

FAQ

Why does ChatGPT work in Proxy but not in Config?

Proxy sends a broader set of requests through the selected SERVER. Config follows the active file’s rules and policies, so a matching rule may send ChatGPT traffic to DIRECT, a wrong group, or an unavailable exit. Compare the rule order and policy target, then keep only the routing change that is necessary.

Why does ChatGPT work on Wi-Fi but fail on mobile data?

The two networks can use different DNS, filtering, permissions, and connection stability. Confirm that both Shadowrocket and ChatGPT may use mobile data, then compare the selected SERVER and DNS behavior on each network. If another VPN or security profile reconnects only on cellular, check On Demand and iOS profiles.

Do I need a new subscription when ChatGPT stops working?

Not automatically. First test Shadowrocket off, then test another SERVER, Proxy, Config, and the other network one at a time. A new subscription is relevant only if the existing source is genuinely unavailable or no longer provides a usable exit; it cannot repair a direct rule, DNS conflict, or iOS VPN collision.

Does Shadowrocket guarantee access to ChatGPT?

No. Shadowrocket is a traffic policy client, not a ChatGPT service or network provider. Results depend on the current network, the exit you prepare yourself, DNS, the active Config, iOS behavior, and the service’s own availability. The goal of troubleshooting is to identify which part changed, not to promise that every exit will work all the time.

If the evidence still points to an installation, import, or basic interface question, continue with the tutorial guide or review the FAQ. Keep the three layers separate, restore a known state after each test, and make the smallest change that explains the result.

Layer one: you only bought the client

What the App Store sold you is a client license. It parses links, stores nodes, measures latency, switches Global Routing, reads and writes config files, and asks the system for a VPN. Those abilities stay after one purchase, and updates stay in the store. It will not invent a working host after you tap “+,” and it will not add traffic or an expiry after you flip the switch.

So “I already paid, why doesn’t it work” is usually not app fraud. The second layer is not connected. SERVER on Home showing only Add Server is the normal state of this layer installed and the next layer still empty. Flipping the switch, reinstalling, or changing region will not fill an empty list.

Layer one can also fail on its own. A look-alike name, a non-store source, or a VPN later turned off in Settings all look like “the app is there but it will not connect.” Those failures should not be fixed by swapping subscriptions. For name, icon, and App ID, see Get Shadowrocket from the App Store only.

Layer two: exits come from a subscription or a typed node

Where the host is, what the port is, whether the protocol matches, whether traffic remains, and whether the link expires are decided by the provider or by your own server. The app only stores those records and connects when you select one. An empty list, a failed update, or latency that all times out: suspect this layer first.

Layer two has two attachments. A provider subscription URL goes through Subscribe in Type and can be updated later. Host, port, and password only go through Add Server. Paste a subscription URL into Host, or treat a config URL as a subscription, and you will not get usable nodes. That misread has its own note: Subscribe is not Add Server.

A list can still mean no exit. Node names are there and every latency is a timeout: the list downloaded, the far end is down. A tiny latency number and pages still fail: the speed-test address is reachable; the proxy handshake may not be. Do not take comfort from the number, and do not reinstall the app because of it. Update the subscription or change a row. If everything still fails, go back to the provider.

Layer three: the config decides which traffic uses the exit

The config does not answer “are there nodes?” It answers “does this request go direct or into the tunnel?” The default default.conf already includes split routing. A provider may also send a remote file. Changing the subscription does not require changing the config, and editing the config is not the same as changing a set of nodes. Both addresses may start with https. They do not belong on the same tab.

When Global Routing stays on Config, what actually applies is the file currently enabled. Extra nodes will not open a site if the rule sends the request to DIRECT. The other way around, if rules also send sites that should stay direct into the tunnel, it feels like “the proxy made things slower.” That is not a broken first layer, and often not a second layer out of traffic. The third layer does not match what you expected.

Why config and subscription must be read apart: A config file is not a subscription. How to use the three observation modes: What Config, Proxy, and Direct are each looking at.

The same “it will not open” points at different layers

A failure in any of the three layers can look like a page that will not open. Changing all three at once only makes judgment harder. Locate from the symptom, then act.

What you seeSuspect firstDo not do this first
Not in the store, or the icon is wrong The app layer: region, listing, a fake Download an installer
SERVER on Home shows only Add Server No subscription imported yet, or Type is wrong Edit rules or turn on Proxy
The list has nodes; every latency times out The exit itself is down Reinstall the app
VPN is up; sites that should stay direct are also slow or fail The config sent requests that should stay direct into the tunnel Keep adding nodes
The switch is on; the status bar has no VPN The system did not allow this configuration Change the subscription URL
The same site also fails on Direct The local network or the target itself is unreachable Keep tweaking Shadowrocket

The system VPN is not a fourth layer, but it is often missed

The connection is written on an iOS VPN configuration. The app requests it; the system allows it. The first time you connect, the system asks whether to add a configuration. Refuse, and the switch on Home cannot take effect by itself. Turn that row off later in Settings and you get the same result: switch on, no VPN in the status bar.

Uninstalling the app does not always delete the system configuration at once. After a reinstall, if you do not allow it again, or Settings still holds a same-named profile from another source, you also get “I installed it, but it will not connect.” That still belongs to layer one and system authorization, not an expired subscription.

On Demand in Settings can disconnect when you leave certain networks. That is not nodes vanishing. People read “it dropped overnight, so the subscription died.” Check this item first, then update the second layer.

A suggested check order

First confirm the app is the official copy and the VPN configuration is still in the system. Then confirm Home has a node you can select, and that an update is not an empty list. Only then ask whether rules sent the request to DIRECT, or into the tunnel by mistake. Touch one layer at a time. Update a subscription, change Global Routing, switch Config, and toggle VPN in the same minute, and you will not know which step took effect.

Uninstalling and reinstalling only clears local state inside the app. Whether the subscription and the config survive depends on a backup in Data, and on whether the system still keeps the VPN configuration. Reinstall is not how you repair the second layer, and it is not a business-recovery key.

Once the three layers are distinct, connect them in order in the tutorial. If you have not purchased yet, or have not matched the icon, use the download page. Do not look for an installer on another site.