Start with the symptom: what “ChatGPT is not working” actually means
If ChatGPT will not load while Clash is running, the first task is to identify which part is failing. A blank page, a sign-in loop, a message that cannot be sent, and a response that stops halfway through can all look like “the proxy is broken,” but they point to different causes. The browser may be using a direct connection, a Clash rule may send one request to the wrong route, the selected node may be slow or unavailable, or an account or service issue may be mistaken for a network problem.
Begin with a controlled comparison. Keep the same browser, device, account, and network. Test ChatGPT with Clash off, then with Clash on, and note what changes. If the site fails in both cases, investigate the browser, account, local network, or ChatGPT service before editing proxy rules. If it works with Clash off but fails with Clash on, routing or proxy adoption becomes more likely. If the page opens but sending a prompt hangs, pay particular attention to the route used by the request that starts or streams the conversation; loading the home page alone does not prove that every connection is healthy.
Also distinguish browser traffic from traffic generated by a separate application. A browser may respect the operating system’s proxy setting while a desktop app, command-line tool, or browser launched with a custom profile follows different settings. For an initial diagnosis, use one browser and one Clash client, close competing proxy or VPN tools, and avoid changing several settings at once. A repeatable test gives you evidence; a sequence of simultaneous toggles gives you guesswork.
- ChatGPT fails in every browser and with Clash disabled: check the internet connection, account sign-in, browser extensions, and service availability first.
- ChatGPT works without Clash but fails with it: inspect the matching connection in Clash, the selected rule, and the node used by that rule.
- The website loads but prompts do not complete: check for unstable nodes, interrupted long-lived connections, or a browser request classified differently from the main page.
- The browser works but another app fails: confirm whether that app uses the system proxy; consider TUN only after simpler proxy settings have been verified.
Do not treat every error as a routing failure. A rejected password, an account verification challenge, or a service-side error is not repaired by switching nodes. Conversely, a page that works only when Clash is set to Global mode is a useful clue: a rule or profile decision may be sending relevant traffic DIRECT, even though the proxy itself can connect.
Inspect Clash Connections before changing rules
Open the active profile in Clash Verge Rev or another Mihomo-based client, confirm that the proxy service is running, and open its Connections or equivalent live-traffic view. Keep that panel visible while you reload ChatGPT and attempt one test prompt. Look for connections created at the time of the failure, including their destination hostname, process if shown, rule match, selected proxy group, and final outbound. The exact labels vary by client version, but the diagnostic question is the same: did the request reach Clash, and where did Clash send it?
ChatGPT does not necessarily use one hostname for every action. The web application can request page resources, authentication, API responses, and streamed content through different hosts or service infrastructure. Providers can also change their implementation. Treat a hostname observed in your own Connections view as stronger evidence than a copied list of domains from an old post. Do not assume that adding one familiar hostname automatically routes every part of the session.
Read the rule and outbound together. A connection marked DIRECT may be correct if your profile intentionally allows that destination to bypass the proxy, or it may reveal a rule that is too broad or ordered too early. A connection sent to a proxy group may still fail because that group selected an unhealthy node. A connection that never appears may not be reaching the Clash core at all: the browser might be using a different profile, the system proxy might be disabled, or the failing program might not honor system proxy settings.
Rule order matters because many rule engines use the first matching rule. If a broad domain, IP, or geographic rule appears before the intended service rule, the later rule may never run. Before editing a subscription-managed configuration, check how your client handles overrides or local rules. Prefer a supported override mechanism over changing generated provider files that may be replaced on the next profile update. Make one narrow, reversible change, reload the configuration, and repeat the same test while watching the connection log.
| What you observe | Likely direction | Next check |
|---|---|---|
| Relevant connection is DIRECT, and Global mode makes ChatGPT work | Rule match, rule order, or profile policy | Inspect the matched rule and use a narrow override if appropriate |
| Connection uses a proxy group but times out | Selected node, group selection, or transport stability | Test another node and compare repeated requests |
| No corresponding connection appears | Browser or application is bypassing Clash | Verify system proxy settings, active profile, and app behavior |
| Page opens, but sign-in or response streaming stalls | Different request routes or an unstable long-lived connection | Watch connections during sign-in and prompt submission separately |
Global mode is useful as a short diagnostic comparison, not necessarily as the permanent fix. If it changes the result, return to your normal mode and use the logs to find the specific policy difference. Leaving every connection on one global route can send local services through an unnecessary proxy, make troubleshooting less transparent, and use more subscription traffic than needed.
Test the rule and node separately
A dependable test separates the policy decision from the quality of the outbound. First confirm that the relevant ChatGPT traffic is assigned to the intended proxy group. Then select a known-working node in that group, rather than relying on automatic selection while you are collecting evidence. If the same request succeeds through one node and fails through another, the problem is more likely to involve that node’s availability, congestion, latency, or compatibility with the connection than the browser’s general proxy configuration.
Run the comparison more than once. One successful page load can be a cached result, and one timeout can be a temporary network fluctuation. Use the same action each time: open a new tab, load the service, sign in if needed, and send a short prompt. Allow enough time for a response, but note whether the failure occurs during initial connection, after a delay, or while content is streaming. Those timings help distinguish a connection that cannot be established from one that is being interrupted later.
When your client exposes proxy-group testing, use it as a rough availability signal, not a guarantee that ChatGPT will work. A latency check may test a different destination and a short connection; it cannot prove that the full web session, authentication flow, or streamed response will remain stable. Likewise, a node with a low displayed delay is not automatically the best choice if it drops longer sessions or becomes congested at busy times.
For a rule test, compare the normal routing mode with a temporary, controlled route for the observed destination or service group. The exact rule syntax depends on the profile and rule format you use, so do not paste an unverified example into a production configuration. If an override is needed, keep it as narrow as your client supports, place it where it can match before conflicting catch-all rules, and confirm the result in Connections after applying it. If the profile is managed by a provider, preserve a copy of your changes and check whether a profile update will overwrite them.
Keep a short record of each test: mode, rule match, group, node, approximate time, and result. Change only one variable between attempts. For example, keep the rule fixed while testing two nodes; then keep the node fixed while testing a rule adjustment. This small discipline prevents a common trap: changing the rule, node, DNS mode, and browser at once, then not knowing which change helped—or which one created a new problem.
Check system proxy settings, then consider TUN
On Windows or macOS, check that Clash’s system proxy option is enabled if the browser is expected to use it. Confirm that no second proxy application is overwriting the operating system setting. If the browser was already open when you changed proxy settings, close and reopen it before testing, particularly when extensions, profiles, or managed settings may affect its network behavior. The precise switch name differs across clients; verify the active status in both the Clash interface and the operating system rather than assuming that selecting a profile automatically enables the system proxy.
System proxy mode is not a universal traffic capture mechanism. Some native applications, command-line programs, and software with their own network stack may ignore it. If ChatGPT works in a browser but a separate client does not, first look for that client’s own proxy configuration and documentation. For command-line tools, a supported proxy environment variable may be more appropriate than changing system-wide routing. Be aware that environment variables only affect processes launched with those variables available; setting them in one terminal does not automatically configure a desktop application.
TUN mode is a broader option that can capture traffic from programs that do not follow the system proxy, subject to the operating system, client permissions, and the Mihomo configuration. It is not the first fix for a browser that already appears in Connections and is simply being sent to the wrong rule or node. Turning it on unnecessarily can change DNS handling, route more applications than intended, or introduce conflicts with another VPN, firewall, or network filter.
Before enabling TUN, verify the system proxy, stop conflicting tunnel or VPN tools, and read the client’s prompts about administrator privileges and network extensions. Enable TUN only if the failing application demonstrably bypasses the normal proxy path and your client supports TUN on that operating system. Test one application at a time. If the problem gets worse, disable TUN and return to the last known working configuration instead of stacking additional DNS and routing changes on top.
- Confirm the baseline: test ChatGPT with Clash off and record whether the same browser and account work.
- Check the active profile: ensure the expected configuration is loaded and the proxy service is running.
- Observe one failure: reload ChatGPT and submit one short prompt while watching Connections.
- Test the route: note the matched rule and outbound; compare a suitable node without changing other settings.
- Verify proxy adoption: check the operating system proxy and restart the browser or application if needed.
- Try TUN only when justified: use it for an application that bypasses system proxy mode, then repeat the same test.
- Restore and document: remove temporary tests, keep the narrow fix that worked, and confirm normal browsing still behaves as intended.
If the problem began immediately after a profile update, compare the current configuration with the last working version before changing unrelated settings. A profile may have altered rule order, group membership, DNS behavior, or node availability. Reverting temporarily can confirm whether the update is involved, but avoid leaving an obsolete profile in place without understanding what changed. Keep credentials and subscription URLs private when sharing screenshots or logs; redact account identifiers, tokens, and other sensitive values.
Confirm the fix and avoid unnecessary changes
A fix is not complete just because the landing page appears once. Verify the full path that originally failed: sign in, send a prompt, wait for the response to finish, and repeat the test after closing and reopening the browser. Then check that unrelated sites and local services still follow the routing policy you intended. If you changed a rule, confirm that the relevant Connections entries now show the expected match and outbound. If you changed a node, test it again later or choose a reliable group policy rather than assuming a single good result proves long-term stability.
If ChatGPT still fails, preserve the evidence rather than adding a long list of guessed domains. Record the exact symptom, whether Clash-off works, the connection’s observed hostname, the matched rule, the selected group or node, and whether the failure happens at connection time or during streaming. This information makes it easier to distinguish a Clash configuration issue from a node outage, a browser problem, or an account-side error. When asking for help, redact private configuration values and avoid posting complete subscription links.
Some lightweight proxy apps make it easy to switch a single endpoint, but may provide limited visibility into rule matches, connection history, or per-application behavior. Clash offers a more inspectable routing workflow: you can compare DIRECT and proxy decisions, test a group or node, and use TUN only when an application does not follow the system proxy. If you want that level of control across supported platforms, choose a Clash client that fits your operating system and configuration needs.