Fix ChatGPT Not Working With Clash: Access and Timeout Guide

First, separate the symptom from the network layer

When ChatGPT stops loading only while Clash is running, the visible symptom does not immediately identify the cause. A blank conversation page, an endless spinner, “network error,” a failed login, or a timeout can be produced by different parts of the connection path. The browser may be using the system proxy while another application bypasses it; the selected node may accept a TCP connection but fail during TLS; DNS may return an unusable address; or a rule may send ChatGPT traffic to a direct connection that cannot reach the service from the current network.

Start with a controlled comparison. Turn off the system proxy and TUN mode, close or pause the Clash client, and test ChatGPT in a private browser window. Then start Clash again without changing the browser, configuration, or network. Record whether the failure affects only chatgpt.com, the login page, file uploads, the API, or every website. This distinction is more useful than repeatedly changing nodes without recording the result.

Check the client mode and local proxy port

Clash does not automatically proxy every application merely because the client window is open. In system proxy mode, the operating system advertises a local HTTP or SOCKS endpoint to applications that respect system proxy settings. In TUN mode, the mihomo core creates a virtual network interface and intercepts a wider range of traffic, including programs that ignore the system proxy. These are different operating modes and should be tested separately.

Verify system proxy settings

Open the Clash client’s General, Settings, or similar runtime page and confirm that the core is running. Check the configured mixed port, which is often 7890, but do not assume that value is universal. The actual port comes from the active configuration. A typical entry looks like this:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

Next, confirm that the system proxy toggle is enabled and points to the same local address and port. If the operating system still points to 127.0.0.1:7890 after the client has changed to 7891, the browser will connect to a closed or unrelated port. The result may appear as “proxy connection failed,” “ERR_CONNECTION_REFUSED,” or a generic timeout.

When testing in a browser, check whether a proxy extension is also active. A browser extension can override the operating system proxy, select a different local port, or apply its own bypass list. Disable the extension temporarily or set it to use the same Clash endpoint. Two proxy layers can create a loop: the browser sends traffic to a local extension, the extension sends it to Clash, and a rule or secondary proxy sends it back to the extension.

Test system proxy before enabling TUN

For a browser test, begin with TUN disabled and system proxy enabled. This is the simplest path because it keeps routing visible and reduces the number of variables. Open a new private window, visit the ChatGPT page, and send a short text-only message. If this works, the basic node, rule, and browser proxy path are probably valid. You can then test TUN separately if another application needs transparent routing.

If system proxy mode fails but TUN mode works, the browser or operating system is probably not applying the expected proxy settings. If TUN fails while system proxy mode works, inspect the TUN interface permission, DNS mode, auto-route setting, and conflicts with another VPN or security product. Do not leave two VPN-style network extensions enabled during diagnosis.

Inspect rules, DNS, and service-specific domains

In rule mode, the first matching rule determines the traffic policy. A configuration can contain a perfectly healthy proxy node while ChatGPT is still sent directly because an earlier GEOIP,DIRECT, DOMAIN-KEYWORD, RULE-SET, or final catch-all rule matches first. The important question is not only “Is the node online?” but also “Which policy handled this hostname?”

ChatGPT access may involve more than one hostname. The main web application commonly uses chatgpt.com and may still contact openai.com, authentication endpoints such as auth.openai.com, static resources, telemetry endpoints, and content delivery domains. The exact list can change with the service, browser, region, and account flow. Avoid copying a random, oversized domain list from an unknown source. Start with the domains shown in the Clash connection log and create the smallest rule adjustment that explains the failure.

A common diagnostic rule is to place explicit domain suffix rules above broad rules:

rules:
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT
  - DOMAIN-SUFFIX,openai.com,ChatGPT
  - DOMAIN,auth.openai.com,ChatGPT
  - MATCH,PROXY

Here, ChatGPT must be the name of an existing policy group. If the group is called Node Select or Proxy, use that exact name. YAML indentation uses spaces, and policy names containing special characters may need to be quoted. A rule that refers to a group which does not exist can fail during parsing or result in unexpected behavior depending on the client and core.

Understand DNS-related failures

DNS problems often look like node problems. With fake-IP mode, the DNS component returns synthetic addresses and keeps a mapping between those addresses and domain names. This normally works with mihomo, but a conflicting DNS service, another VPN, a manually configured resolver, or an application that performs its own DNS lookup can break the mapping. Symptoms include a page that partially loads, a TLS error for the wrong host, or connections that remain pending even though the rule log shows the expected policy.

For diagnosis, compare the current DNS mode with a simpler configuration. If fake-IP is enabled, temporarily test redir-host or the client’s recommended compatible mode. If the problem disappears, review fake-ip-filter, DNS listen addresses, and applications that must bypass fake-IP. Do not permanently copy DNS settings from a different client without checking whether the current mihomo build supports every field.

Also check whether the selected node resolves the remote address through the intended path. A configuration may use direct DNS for domain resolution while sending the subsequent HTTPS connection through a proxy, or it may use a proxy DNS server. Either design can work, but inconsistent interception can expose a stale or unreachable address. The Clash log should show the hostname and the final policy; use that information instead of relying only on the browser’s error page.

Run a controlled test: node, rule, and TUN one by one

The following procedure is designed for FlClash, Clash Verge Rev, ClashX, Clash for Android, and other clients that expose similar core controls. Menu names differ, but the logic remains the same. Keep the original profile backed up before editing YAML or overrides.

1. Confirm the core status. Start the active profile and verify that the log does not show a YAML parse error, a port bind failure, or a DNS startup error. If the profile failed to load, node testing is premature.
2. Use system proxy mode first. Disable TUN, enable the system proxy, and confirm the operating system points to the active mixed port, such as 127.0.0.1:7890.
3. Select a known working policy group. In the proxies panel, choose a node manually rather than Auto or URL-Test. Wait several seconds for the selection to take effect and avoid judging a node solely by latency; a fast ICMP or HTTP probe does not prove that ChatGPT’s complete HTTPS flow works.
4. Watch the connection log. Open a private browser window, load https://chatgpt.com, sign in if needed, and send a short message. Look for entries containing the relevant hostname, the selected policy, DNS errors, TLS failures, resets, or repeated retries.
5. Test a second node from a different route. Choose a node in another region or provider group. If one node works and another consistently times out, the rule is likely correct and the issue is upstream node quality, destination reachability, or server-side filtering.
6. Test the explicit rule. Temporarily place a narrowly scoped DOMAIN-SUFFIX rule for chatgpt.com and openai.com above broad rule sets. Reload the configuration, clear only the relevant browser tab, and repeat the same message test.
7. Test TUN last. Re-enable TUN with the system proxy state understood. Confirm that auto-route is enabled if the client provides it, and disable other VPNs. If TUN changes a working test into a timeout, compare DNS and route settings rather than replacing the subscription immediately.

A useful test matrix helps prevent guesswork:

After the test, remove temporary rules that are no longer needed. Keeping several overlapping ChatGPT rules can make later subscription updates difficult to understand, especially when a provider rule set is inserted above local rules.

Read timeout and connection logs correctly

A timeout is a timing result, not a complete diagnosis. The relevant phase matters. A DNS timeout means the hostname was not resolved in time. A TCP connection timeout means the selected route could not establish a connection to the destination. A TLS handshake timeout means a connection began but negotiation did not complete. A read timeout means the connection was established but no expected data arrived. A reset can be caused by the remote server, an intermediary, a node with unstable transport, or a local security filter.

• Connection refused: Check whether the local mixed port is listening and whether another process owns the configured port.
• Proxy connection failed: Confirm that the browser is using the correct system proxy address and that the Clash core is running.
• DNS error: Compare fake-IP and redir-host behavior, inspect the configured resolver, and look for another VPN intercepting DNS.
• TLS handshake timeout: Test a different node, check the system clock, and inspect whether a security application is scanning HTTPS traffic.
• Connection reset: Compare multiple nodes and networks. A reset limited to one node is usually not fixed by editing browser settings.
• Repeated retries: Check whether the policy group is URL-Test or fallback and whether health checks are repeatedly switching nodes during the request.

Increase logging temporarily to info or debug only while reproducing the issue. Debug logs can include hostnames, request metadata, and internal details, so do not publish them without removing subscription tokens, credentials, cookies, and private addresses. After collecting evidence, return to warning or info to reduce noise and avoid unnecessary disk writes.

If the browser page loads but the conversation stream stops, test a plain text response before file upload, voice, or image features. Large transfers and long-lived streaming connections put more pressure on node bandwidth and idle timeout settings. A node can pass a quick latency check yet fail after a conversation remains open for several minutes. In that case, use a more stable node or policy group rather than lowering every timeout value globally.

Apply a stable fix and know when to stop

Once the failing layer is identified, make the smallest permanent change. If the selected node is the problem, remove or deprioritize it in the policy group and let a health check compare several alternatives. If the rule is the problem, keep a specific domain rule above the broad provider rules. If DNS is the problem, use the DNS mode recommended by the current mihomo configuration and verify that TUN, fake-IP filters, and other VPN components do not conflict. If the local proxy is the problem, correct the port and system proxy state before touching the subscription.

Keep the configuration maintainable. A practical arrangement is to place local, high-priority service rules first, provider rule sets next, private-network and LAN rules where required by the design, and a final MATCH rule at the bottom. Ensure the referenced policy group exists and has at least one usable proxy. When a subscription refresh replaces generated sections, store local adjustments in the client’s supported override mechanism instead of editing generated YAML repeatedly.

There are also cases where Clash is not the cause. If ChatGPT fails with Clash stopped, fails through every tested node, or fails from multiple devices and networks at the same time, the likely causes include account authentication, service availability, regional reachability, provider policy, or an upstream outage. Reinstalling the client will not repair an unavailable remote service. Compare the same account and browser from a clean network, check the service’s official status information, and preserve the exact time and error for later comparison.

Finally, avoid exposing your subscription URL while asking for help. The URL may contain a token that allows anyone who obtains it to consume traffic or access account information. Replace the token with a placeholder, remove cookies and authorization headers, and share only the relevant rule, error category, client version, core type, operating system, and test result. For a clean installation path and platform-specific packages, visit the download center; for basic profile import and proxy setup, follow the quick-start guide.