Start by classifying the ChatGPT timeout
When ChatGPT keeps loading through Clash, the visible symptom does not identify the cause. A blank conversation, a spinner that never finishes, a failed sign-in redirect, and an answer that stops halfway through can come from different parts of the connection path. Before changing your profile, note exactly what failed and when: opening the site, signing in, sending a prompt, streaming a response, or uploading a file. Then check whether the same action works with Clash paused or with a different network, if that test is appropriate for your setup.
This guide is for people using a Clash-compatible client such as Clash Verge Rev, Clash Verge, or another Mihomo-based app. The goal is not to route every device or service through one group blindly. It is to determine whether ChatGPT traffic is being sent to the intended proxy, whether the selected node can sustain the connection, and whether DNS or TUN settings are interfering. Make one change at a time so that each test tells you something useful.
A timeout is different from an account or application error. If ChatGPT returns a clear message about a sign-in challenge, account access, or a service problem, address that message rather than repeatedly changing Clash rules. If the page loads but requests consistently hang only while the proxy is active, network routing is a more plausible place to investigate. Keep credentials, session cookies, subscription URLs, and private conversation content out of screenshots and support posts.
Check Clash mode and rule matching before editing YAML
First confirm that Clash is actually running with the profile you expect. A client can appear connected while using a stale configuration, an unselected proxy group, or a mode that sends the relevant request directly. In Rule mode, the profile’s rules decide whether each connection uses a proxy group, goes DIRECT, or is rejected. In Global mode, traffic is generally directed through the selected global group, which can be useful as a short diagnostic comparison but is not automatically the best permanent configuration.
Open the client’s Connections or equivalent live-traffic view while reproducing the failure. Look for connections created at the moment you load ChatGPT or submit a prompt. Record the hostname, rule, matched policy, selected group, and whether the connection closes, retries, or remains pending. Hostnames can change as the site’s web app, authentication flow, static assets, and API requests use different services. Treat the live connection list as evidence; do not assume one memorized domain list covers every request.
- If a relevant connection shows DIRECT: inspect rule order and the matched rule. A broad direct rule, a domain-set rule, or a rule placed above your intended proxy rule may be taking precedence.
- If it shows a proxy group but the wrong node: check the group selection and health-test result. A group may be set to automatic selection, pinned to a failed node, or pointing to a provider group that has no usable members.
- If the connection is rejected: inspect reject rules, ad-blocking filters, and profile overrides before adding another routing rule.
- If no relevant connection appears: the browser may be using another network path, a system proxy setting may not be active, or a TUN-related capture issue may be preventing the request from reaching Mihomo.
As a controlled test, switch temporarily to Global mode and select a known working node, then repeat the same ChatGPT action. If it works in Global mode but not in Rule mode, the contrast points toward rule matching, DNS policy, or a group choice rather than proving that every request needs a permanent global tunnel. Return to your normal mode after the test and make the smallest policy adjustment that explains the observed traffic.
Separate node health from a ChatGPT service or account error
A green latency check does not guarantee that a node will carry a long, streaming HTTPS response reliably. Many client health tests measure a short connection to a test URL; they do not reproduce ChatGPT’s authentication redirects, request duration, response streaming, or the route to every service involved in the web app. A node can pass a quick test and still have packet loss, unstable throughput, or a poor path for the destination you are testing.
Compare a small number of variables rather than cycling through every node at random. Keep the same browser, prompt, Clash mode, and profile, then try one other node in the same provider group. If both fail in the same way, test a node from another available group or a different trusted connection. If one node consistently works while another times out, the evidence favors a node or provider path problem. If every node behaves identically, investigate rules, DNS, browser state, and client capture before concluding that all nodes are defective.
Pay attention to where a request fails. A sign-in page that never completes may involve a different hostname from the conversation request. A response that starts and then stops can point to an unstable long-lived connection even when the initial page opened successfully. If only a particular browser profile fails, test a clean private window or another browser after considering your privacy and account-security requirements. Extensions, stale site data, and blocked cookies can cause application behavior that looks like a proxy timeout.
Also compare with an unrelated HTTPS site using the same Clash path. If general browsing fails too, troubleshoot the node, client connection, or local network first. If unrelated sites work but ChatGPT does not, inspect the ChatGPT-related connection rows and the specific route they match. When the provider itself is unstable, changing a domain rule will not repair packet loss; when the provider is reachable and the connection is DIRECT by mistake, buying another subscription is unlikely to solve the routing error.
Use DNS and TUN checks only when the evidence points there
DNS issues can make routing appear inconsistent because a domain may resolve differently across the system, the browser, and Clash. Fake-IP mode, redirection settings, and resolver configuration vary among profiles and clients. Do not switch DNS modes simply because a timeout occurred. First check whether the failing hostname appears in the client’s connections and whether its resolution or matched policy differs from a working request. If the client exposes DNS logs, use them to confirm that the name is being resolved through the resolver configured for the profile.
When a hostname works in one mode but not another, check whether the profile’s DNS settings agree with its routing approach. A mismatch between fake-IP behavior and the client’s traffic-capture method can create confusing results, including connections that appear under an unexpected address or rules that do not match as intended. Prefer a temporary, reversible test using the client’s documented DNS options. Record the original values before changing them, then restore them if the test makes no measurable difference.
TUN is relevant when ordinary system-proxy handling does not capture the browser or a particular application. In Clash Verge Rev or another Mihomo client, confirm that the TUN service is enabled only if your setup requires it, that the operating system granted the requested network permissions, and that no second VPN or network extension is competing for traffic. On desktop systems, overlapping proxy clients can overwrite system proxy values or install competing routes. Disable one capture mechanism at a time during diagnosis instead of leaving multiple tools active and guessing which one handled the connection.
QUIC and HTTP/3 can also complicate a comparison because browser traffic may use UDP where a proxy path or local network handles TCP more reliably. If the browser shows repeated failures and the client’s logs suggest an unreliable UDP path, a temporary browser-level test that encourages TCP can help isolate the transport. Treat that as a diagnostic, not a universal fix: restore the original browser behavior if the test changes nothing, and do not disable security checks or certificate validation to make a page load.
Run a controlled troubleshooting sequence
Use this sequence in the middle of the investigation, after you know what action fails. It is designed to change one factor at a time and preserve a clear comparison between tests. Menu labels differ by client version, but the evidence to collect is the same.
- Capture a baseline. Keep the current profile and mode. Open the client’s live connections or logs, reproduce one failure, and note the hostname, matched rule, policy group, selected node, and approximate time. Avoid making several profile edits before you have this baseline.
- Verify the selected route. Confirm that the relevant connection is using the intended group. If it is DIRECT or rejected unexpectedly, inspect the rule that matched and its position relative to broader rules. Make a targeted adjustment only when the log supports it.
- Compare one known node. Select a node that has recently passed a health check, repeat the same action, and then—if needed—compare one other node. Keep the mode, browser, and profile unchanged so the result remains interpretable.
- Use Global mode as a short diagnostic. If Rule mode fails, select a working global group and retry once. Success only in Global mode narrows the investigation to policy selection or related DNS behavior; it does not mean Global mode must remain enabled.
- Check another browser context. If Clash logs show the expected route but the browser still fails, try a private window or a second browser. Do not copy passwords or session tokens into diagnostic tools, and avoid clearing all browser data unless you understand which sessions will be removed.
- Test capture and DNS selectively. If the browser’s traffic is absent from Clash, review the system proxy or TUN state. If the connection is visible but name resolution or matching looks wrong, test the client’s documented DNS options. Change one setting, repeat the same action, and restore the original setting if there is no improvement.
- Return to the simplest working setup. Once a test identifies the likely cause, remove temporary overrides and restore your normal mode. Keep only a narrow rule or stable node selection that the evidence supports, then verify that unrelated sites still follow the routes you intended.
This process is more useful than repeatedly refreshing the page because it gives each attempt a purpose. A working Global-mode test, for example, says something different from a successful node swap. Likewise, a connection that never appears in Mihomo logs calls for a capture-path check, not another hostname rule. Keep short notes of the settings and results so you can undo experiments instead of accumulating unexplained overrides.
Keep the fix narrow and verify it after changes
Once ChatGPT works, verify the result with more than one action: load the page, sign in if needed, send a short prompt, and allow a response to finish. If your typical use includes longer outputs or file uploads, test those separately because a brief page load does not prove that a longer session will remain stable. Check the Connections view during each test and confirm that the relevant requests continue to use the intended group.
Prefer a specific, explainable rule over a broad catch-all if your profile supports domain-based policies. Put targeted rules before general rules that would otherwise take priority, and avoid copying large rule blocks from old posts without checking current connection logs. Keep changes in the client’s supported override or profile workflow so that a subscription refresh does not silently erase them. Before editing a profile directly, save a backup and make sure you can restore it.
If the issue returns after a profile update, node rotation, browser update, or client restart, compare the new connection log with your earlier notes. The failing request may now use a different hostname, the active group may have changed, or the client may no longer be capturing traffic through the same mechanism. Re-test rather than assuming that yesterday’s rule still matches today’s route. If all nodes fail while other sites remain reachable, share only sanitized diagnostic details with your provider or client community; remove subscription links, tokens, IP addresses, and account information first.
Compared with one-click VPN apps that offer little visibility into which connection used which route, Clash can expose matched rules, groups, nodes, and live connections, making a ChatGPT timeout easier to isolate without routing everything permanently through one tunnel. That flexibility is useful only when you change settings deliberately and verify the result. If you need a supported client for your device, the Clash download page is the practical next step.