Why ChatGPT times out through Clash

If ChatGPT opens normally in one browser but repeatedly shows a timeout, endless loading spinner, or “network error” when traffic passes through Clash, the problem is usually not solved by pressing retry. The failure may come from a rule that sends OpenAI traffic to DIRECT, a proxy node that cannot maintain long HTTPS or streaming sessions, DNS resolution that returns an unusable address, or a client mode that does not cover the application you are using.

This guide is for users running Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, or another Mihomo-based client. It focuses on observable troubleshooting rather than risky system changes. You will classify the symptom, inspect the actual connection in the client, test DNS and proxy reachability separately, check rule order, compare nodes, and confirm whether the application is using the proxy you think it is using.

The goal is not to force every connection through a tunnel. A reliable configuration should route ChatGPT and its required supporting domains through a suitable proxy while leaving ordinary local services on DIRECT when that is appropriate. This split approach usually makes debugging easier, reduces unnecessary traffic, and avoids breaking unrelated websites.

Classify the failure before changing settings

Start by recording exactly what fails. “ChatGPT does not work” can describe several unrelated incidents. Open the service in a private browser window, wait for the failure, and note whether the page itself loads, whether login completes, and whether the error appears when sending a prompt or generating a response.

  • Immediate page failure: the browser cannot establish a usable connection to the web application. Suspect DNS, a blocked hostname, an incorrect rule, or a dead proxy.
  • Login loop: the main page may be reachable, but authentication, redirect, cookie, or verification requests are being routed inconsistently.
  • Prompt submission timeout: the initial HTTPS connection works, but the selected node, rule, or streaming path cannot sustain the response.
  • Uploads fail while text prompts work: file and image requests may use different hostnames or longer-lived connections, so a rule covering only the main site is incomplete.
  • Only the desktop app fails: the application may ignore the system proxy, use its own network stack, or require TUN mode rather than a browser-style HTTP proxy.
  • Global mode fixes everything: this is strong evidence of a rule, DNS, or policy problem rather than proof that every part of Clash is broken.

Also test another ordinary website and one service that you normally access through the same proxy group. If all traffic is slow, investigate the node or local network first. If only ChatGPT fails, concentrate on domain matching, DNS behavior, TLS negotiation, and long-lived HTTPS sessions.

Use the Connections panel as your source of truth

Do not begin by editing a large YAML file from memory. Reproduce the failure while the Clash client is open, then inspect its Connections, Logs, or equivalent traffic panel. Search for the hostname associated with the failing request and check the selected rule, policy group, destination address, and connection state.

A healthy-looking browser page is not enough. ChatGPT can make several requests for page assets, authentication, conversations, files, and streamed responses. The relevant rows may appear under different hostnames. Record a few observations instead of focusing on a single request:

  • Does the request match an OpenAI-related rule, a general proxy rule, or FINAL?
  • Is the policy shown as your intended proxy group, or does it say DIRECT?
  • Does the row repeatedly reconnect, remain pending, or close immediately after the request starts?
  • Does the destination resolve to an address that changes between attempts?
  • Does the selected group contain available nodes, or is it selecting an expired, unavailable, or overloaded member?

If the client records the request as DIRECT while your intention was to proxy it, the first problem is routing. If it uses the expected group but repeatedly times out, test another node before changing DNS. If no matching row appears at all, the application may not be using Clash, or the client may be operating in a mode that does not capture that traffic.

When investigating, change one variable at a time. For example, keep the rule set unchanged while switching from one node to another. Then restore the original node and compare Rule mode with Global mode. This creates evidence that can distinguish a policy error from a weak relay.

A controlled troubleshooting sequence

The following sequence is designed to avoid random configuration changes. Complete it in order and keep a short note of the result after each step. If a step resolves the problem, you can stop and make only the smallest permanent change needed.

  1. Refresh the profile: update the subscription or profile in Clash, confirm that the proxy group contains current nodes, and check the profile’s last update time. Do not paste a private subscription URL into screenshots or public support posts.
  2. Select a known healthy node: choose a node that successfully opens several HTTPS websites and is not showing a failed health check. Avoid judging a node only by ping latency; a low ping does not guarantee stable streaming or reliable TLS traffic.
  3. Test Global mode briefly: enable Global mode for a controlled test, open a private browser window, and send a short prompt. If the timeout disappears, return to Rule mode and inspect the matching rule rather than leaving Global mode enabled permanently.
  4. Inspect the live request: while submitting the prompt, watch Connections. Confirm that the request is captured, assigned to the intended group, and not closing repeatedly before the response begins.
  5. Test a second node: switch to another region or provider member in the same group. If only one node fails, the policy is probably functional and the original node is unhealthy or unsuitable for long connections.
  6. Test the application path: compare the browser with the ChatGPT desktop application or another client. If the browser works but the application does not, investigate system proxy support, TUN capture, and application-specific proxy settings.
  7. Return to Rule mode: once you have evidence, restore the intended mode and apply the narrowest rule or policy correction. Retest login, a normal prompt, and a longer streamed response.

For command-line diagnostics, use a harmless HTTPS request to a hostname you are authorized to test. A command such as curl -I https://example.com can show whether the terminal has general connectivity, but it does not prove that ChatGPT traffic follows the same path. If your shell uses environment variables such as HTTPS_PROXY, confirm that the terminal process actually inherited them. A desktop client and a terminal launched from another session can have completely different proxy behavior.

Do not treat a successful HTTP header request as proof that a long ChatGPT response will work. Streaming connections, larger payloads, and repeated API calls exercise the node differently from a small page request. The useful result is a repeatable comparison between the same application, same rule mode, and different nodes.

Fix rule matching and policy selection

Rule-based mode depends on order. A broad rule placed above a more specific rule can capture a request before the intended policy sees it. For example, a general regional rule, a category rule, or an early GEOIP decision may send an OpenAI-related destination to DIRECT even though a later proxy rule appears correct when you read the file from top to bottom.

Use the actual hostname displayed in Connections and search for the rule that matched it. Do not add a long list of guessed domains simply because they appear in a forum post. Service infrastructure changes, and unnecessary rules make future diagnosis harder. A practical policy arrangement usually has these properties:

  • Specific service rules appear before broad regional, category, or fallback rules.
  • The service rule points to a stable proxy group rather than a single node that may disappear.
  • The group has a clear fallback or health-check strategy, if supported by your client and profile.
  • FINAL is treated as a deliberate last resort, not as evidence that every unmatched request should be proxied.
  • Local login pages, private network destinations, and services that must remain local are not accidentally sent through the same remote group.

After changing a rule or override, reload the configuration and close existing browser tabs or application sessions. Long-lived connections can retain the old route, and a page reload alone may not terminate every background request. Clear only relevant site data if authentication appears corrupted; avoid deleting all browser data before you have established that cookies are actually involved.

Investigate DNS, fake-IP, and TLS behavior

DNS problems can look like proxy problems because the client may receive an address that is unreachable, blocked, or inconsistent with the selected routing mode. Check whether Clash is using its configured DNS engine, the operating system resolver, or a fake-IP strategy. The correct choice depends on the client, profile, and network environment; there is no universal DNS switch that fixes every timeout.

Common clues include a hostname that fails only in Rule mode, connections that appear to target an unexpected address, or repeated resolution errors in the log. Compare a fresh request after restarting the client with a request made before the restart. If behavior changes temporarily, a stale resolver cache or a damaged fake-IP mapping may be involved. Restarting Clash can be a useful diagnostic step, but it is not a substitute for understanding why the mapping became unusable.

Be cautious with fake-IP exclusions. Adding broad exclusions can create leaks or make some applications bypass the routing design, while excluding too little can confuse software that expects the original hostname. If you use TUN mode, check that the client’s DNS hijacking and auto-route options are compatible with the operating system. If you use only system proxy mode, remember that some applications will not send DNS or traffic through that path.

TLS errors deserve separate attention. A certificate warning, handshake reset, or message about an untrusted certificate may indicate a node problem, local security software, enterprise inspection, or an incorrect system clock. Do not install an unknown certificate merely because a prompt suggests it. First test another trusted node, verify the device time, temporarily account for security software according to your organization’s policy, and read the full error in the log.

Choose a node that can sustain ChatGPT sessions

ChatGPT is more demanding than a quick webpage. A node can pass a simple connectivity check while failing when the response streams for several minutes, when an upload is included, or when many HTTPS connections are opened in parallel. Shared relay congestion, aggressive connection limits, packet loss, and poor international routing all produce timeout-like symptoms.

Compare nodes using the same prompt and the same browser session. Give each node enough time for a fair test, but do not repeatedly retry a visibly failing endpoint. Note whether the failure occurs during connection setup, after the prompt is accepted, or halfway through generation. A setup failure points toward reachability or TLS; a mid-response failure points more toward stability, congestion, idle timeouts, or transport handling.

If your client supports automatic health checks, understand what they measure. A health check may request a small URL and report latency, while ChatGPT needs sustained HTTPS traffic. Prefer a group with sensible fallback behavior, and remove or disable nodes that fail consistently instead of allowing automatic selection to return to them every few minutes.

Check whether the application is covered

When ChatGPT works in a browser but the desktop application times out, compare the proxy paths rather than assuming the service has different availability. System proxy mode commonly covers browsers that honor operating-system settings, but an application may use a separate network library, ignore system proxy settings, or maintain connections outside the browser’s process.

On Windows and macOS, verify whether the system HTTP and HTTPS proxy entries point to the active Clash mixed port. Confirm that the port has not changed after a profile update. If another VPN or proxy tool is running, disable overlapping system integration while testing. Two applications can repeatedly overwrite the same proxy settings, creating a connection that appears enabled in one interface but points to a closed port.

TUN mode can capture applications that ignore system proxy settings, but it should be enabled deliberately. Check that the client has the required permissions, that auto-route is functioning, and that another VPN is not competing for the default route. On Android, review the system VPN indicator and confirm that battery-saving settings are not suspending Clash in the background. On macOS, inspect network extension permissions if the client reports that TUN cannot start.

Do not enable TUN, change DNS, and replace the entire profile at the same time. If the application starts working afterward, you will not know which change mattered, and you may create new problems for local services. Establish a browser baseline, then test the application with one capture method at a time.

Make the fix durable and safer

Once ChatGPT works again, document the successful conditions: client name and version, operating system, mode, selected group, DNS strategy, and the rule that matched the request. Export or back up the profile before editing it. If your provider regenerates profiles, prefer a supported override or rule provider instead of manually modifying a generated file that will be overwritten during the next update.

Keep the configuration narrow. Route only the domains and applications that require the proxy, use a maintained group with more than one viable node, and leave local services on DIRECT when that matches your privacy and network requirements. Review the setup after profile updates because rule order, group names, and DNS options may change. A quick test of page loading, login, prompt submission, and a streamed response is more useful than assuming yesterday’s result still applies.

Compared with many one-click VPN tools that hide routing decisions, offer limited logs, or make it difficult to tell whether a timeout came from the server or the tunnel, Clash gives you visible connections, selectable policies, rule-level control, and node comparison in one workflow. That transparency is especially useful for ChatGPT because you can verify whether the browser or desktop app is actually covered instead of repeatedly changing system settings without evidence. If you want a client that makes these checks practical across supported platforms, Download Clash for free and browse freely →