Fix ChatGPT Not Working With Clash: Access and Timeout Checks

Separate ChatGPT availability from Clash routing

If ChatGPT does not load while Clash is running, first identify what is failing: the service or account, the local proxy connection, the selected proxy node, or the rule that handles ChatGPT traffic. These layers can produce similar browser messages, including a blank page, a repeated sign-in prompt, or a timeout, but they require different fixes.

Clash clients such as Clash Verge Rev and other Mihomo-based apps manage configuration and traffic-capture settings. The mihomo core accepts connections, matches rules, and establishes outbound connections. A working subscription does not by itself confirm that your browser is using the local proxy, that a rule sends ChatGPT through a proxy group, or that the selected node can reach the destination.

Before changing rules, check whether the service is reachable from another network and whether the account can sign in. Service availability, supported regions, account requirements, and network policies may change; check the service’s current official status and access information. A proxy timeout cannot fix a service outage, account restriction, or a network policy that prohibits the connection.

Check proxy mode, node, and rule match

Start with the client’s current mode and the connection log. Use Rule mode for a normal rules-based test. In this mode, mihomo evaluates the configured rules from top to bottom and uses the outbound selected by the first matching rule. Global mode and Rule mode are not equivalent: Global mode generally routes captured requests through a selected policy, while Rule mode follows the configuration’s rule list.

1. Confirm that the configuration is active. Select the intended profile and check the core log for startup errors, invalid YAML, missing rule-provider data, or references to nonexistent policy groups.
2. Check the browser request in the connection log. Reload ChatGPT and look for newly created connections. Depending on the client, the log may show a hostname, destination IP, matched rule, policy group, and outbound.
3. Follow the policy group to its final outbound. A rule may point to a group called PROXY, AI, or another name chosen by the configuration author. Expand the group and verify that it ultimately selects a usable proxy node, not DIRECT or REJECT.
4. Test with one stable node. Select a specific available node manually for the initial test. Automatic groups such as url-test or fallback can switch members, which makes results harder to compare.
5. Check rule order before adding exceptions. A broad domain rule, provider rule, or earlier policy can match before a later ChatGPT-specific rule. Adding a rule at the bottom may have no effect if an earlier rule already matches.

ChatGPT and sign-in pages can make requests to multiple hostnames. Do not assume that one visible page hostname represents every request needed for loading, authentication, or related web assets. In the log, inspect the actual hostnames that fail and the rules that handle them. If you add a domain rule, use a supported rule type and put it before broader rules that would otherwise match first.

# Illustrative rule snippet only; merge into the existing rules section
rules:
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - MATCH,DIRECT

This example is not a complete configuration. Replace PROXY with the exact name of an existing proxy or policy group, and retain the configuration’s intended final rule. A domain suffix rule can match the named domain and its subdomains, but it cannot guarantee that every related service request uses the same domain. Use log evidence to decide whether a rule is necessary; avoid copying large, unverified domain lists into a subscription override.

Run a controlled System Proxy test

Use this middle-of-troubleshooting test to determine whether the browser is reaching Clash through the system proxy and whether a request can pass through the selected route. First, pause other proxy clients and browser proxy extensions. Enable the Clash system proxy, keep the client in Rule mode, and note the active local proxy port. The port below, 7890, is only an example; check your client’s active listener settings.

Test the local proxy listener

From a terminal, send an explicit HTTPS request through the local HTTP proxy. This bypasses uncertainty about whether a command-line program reads the operating system’s proxy settings.

# macOS / Linux
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 25 https://chatgpt.com/

# Windows PowerShell
curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 25 https://chatgpt.com/

Replace 7890 with the actual HTTP or mixed-port listener. If the client exposes only a SOCKS listener, use its configured SOCKS URL instead, such as socks5h://127.0.0.1:PORT; replace PORT with the real value. The h in socks5h asks curl to resolve the hostname through the proxy rather than resolving it locally.

• Connection refused immediately: Check that the core is running, the port is correct, and the listener is bound to the expected local address. A refused connection usually occurs before a remote node is tested.
• The local proxy accepts the request, but curl times out: Inspect the Clash log for the hostname, matched rule, selected policy group, and outbound error. A remote connection, DNS, or network path may be failing.
• Curl returns an HTTP status: The request received an HTTP response, but the status alone does not confirm that ChatGPT will work in a browser. Redirects, access checks, and authentication can produce responses that require further interpretation.

Compare the browser with the terminal

Open a private browsing window with extensions disabled and load ChatGPT while watching the connection log. If curl succeeds but the browser has no corresponding log entries, the browser may be bypassing the system proxy, using a custom proxy, or resolving the destination through a different network path. Check its proxy settings and any extension that controls proxy behavior.

If both curl and the browser create log entries but fail at the same outbound, investigate the policy group and node before changing browser settings. If the browser loads the page shell but authentication or another request fails, inspect the other failed hostnames in the log rather than assuming the first successful request proves the whole service is reachable.

When to test TUN mode and DNS

System Proxy is a useful first test for a desktop browser that honors operating-system proxy settings. TUN mode is different: it uses a virtual network interface to capture traffic that may not use the system proxy, subject to the client’s routing, DNS, and permission settings. Enabling TUN does not automatically force every connection through a proxy; captured traffic still follows mihomo’s rules.

Test TUN separately rather than enabling it at the same time as changing the node, rules, and DNS. Close or pause other VPN and traffic-capture software, grant the client the requested system permission, and check that the TUN interface starts without an error. Then reload ChatGPT and inspect the connection log. If there are no relevant entries, check whether the interface is active and whether the browser traffic is actually being captured. If entries appear with a DIRECT outbound, the rule—not the capture method—may explain why that request is not using a proxy.

DNS can affect which address a hostname resolves to and whether a request reaches the intended destination, but changing DNS alone will not repair a broken proxy node or an incorrect policy group. First determine whether the failure is a local name-resolution error or a remote connection timeout. Compare log entries for the same hostname, note whether the connection has a resolved destination, and avoid switching between fake-IP, redirection, and nameserver settings without a specific reason.

On laptops, also test without a captive portal, hotel sign-in page, or restrictive public Wi-Fi in the way. Corporate networks may block VPNs or proxy connections; consult the network administrator rather than trying to bypass workplace controls. Where possible, compare with a permitted, trusted network while keeping the Clash configuration and browser unchanged.

Interpret timeouts and apply a fix

A timeout is a symptom, not a diagnosis. The point at which it occurs matters. A browser that cannot connect to 127.0.0.1 has a different problem from a local listener that accepts a request but cannot establish an outbound connection. Use the client’s connection log and core log to distinguish those stages, then make only the change supported by the evidence.

• No local connection in the log: Confirm the selected profile is enabled, the client’s traffic-capture method is active, and the browser is configured to use it. For an explicit curl test, verify the listener port and scheme.
• Rule matches DIRECT: Review rule order and the actual matched rule. Add or adjust a narrowly scoped rule only if the configuration should route that hostname through a proxy.
• Rule matches a proxy group, but the final outbound is unavailable: Check the group’s selected member, node status, and core errors. Test one other available node without changing the rule.
• One hostname works while another repeatedly fails: Inspect the failing hostname and its matched rule. Authentication, page assets, and API requests can use different destinations; do not assume a partial page load means the browser is fully connected.
• The same route fails only on one network: Check for DNS filtering, firewall restrictions, captive portals, or a network policy. Do not treat a configuration change as a solution to restrictions you are not authorized to bypass.
• Connections succeed but sign-in still fails: Check the account, browser cookies, system time, and extensions separately. Avoid deleting all browser data until you have noted whether a private window or another supported browser behaves differently.

After a successful test, restore any temporary setting that was not part of the fix. If you tested TUN only to diagnose a browser issue, turn it off again when it is not needed. Keep the final configuration consistent with the intended traffic policy, and confirm that ordinary sites still follow their expected rules.

For a useful support report, record the client and operating system, whether you tested System Proxy or TUN, the time of the failure, the matched rule and policy group, and the error category shown in the core log. Redact subscription URLs, node credentials, IPs where appropriate, cookies, and account information. A concise record of what changed between tests is more useful than an unredacted full log or a list of simultaneous configuration edits.