ChatGPT Not Working With Clash? Fix Timeouts and Access
Start by identifying where the request fails
“ChatGPT does not work with Clash” can describe several different failures: the page never loads, sign-in stalls, messages time out, or the page opens but responses do not arrive. Those symptoms can come from different layers. The browser or app may not be sending traffic to the local proxy; Clash may match the request to DIRECT; the selected proxy may be unreachable; DNS may return an unusable address; or the remote service may be temporarily unavailable.
Begin with one controlled test rather than changing several settings at once. Use the same device, browser, network, and ChatGPT account for each test. Note the time, the exact symptom, and whether other websites load through the same proxy. Also check the service’s official status information and any network restrictions that apply to your location or organization. A successful connection to another website does not prove that every ChatGPT-related hostname follows the same route.
Keep the original configuration intact. If you need to test a temporary rule or DNS change, make a copy or record the original value first. Avoid posting subscription URLs, authentication tokens, account details, or screenshots containing private connection information when asking for help.
| Symptom | Likely layer to inspect | First useful evidence |
|---|---|---|
| The page does not open at all | Browser proxy, system proxy, TUN routing, DNS, or node connectivity | Whether a new request appears in Clash’s “Connections” page |
| The page loads, but sign-in keeps spinning | Routing or filtering of an authentication or supporting hostname | The requested hostname and matched rule for each stalled request |
| The site opens, but a prompt times out | Selected node, packet loss, DNS, or a long-lived connection interrupted in transit | Whether the same node can load other sites and whether the failure is repeatable |
| Only one browser or app fails | That application’s proxy behavior, extensions, private DNS, or cache | A comparison with another browser or a command-line request using the local proxy |
| All sites fail through Clash | Core status, local listening port, configuration, or network access to the node | Core startup logs and a test to an unrelated website through the same local proxy |
Check the proxy mode, matched rule, and selected node
First confirm that the configuration is loaded and the core is running. In the client, check the active profile and the core’s startup status. Then inspect the current mode. In Rule mode, the core evaluates rules in order and uses the first matching rule. In Global mode, traffic received by the core is sent through the selected global proxy or proxy group. In Direct mode, traffic is sent out without the configured proxy route. These modes do not make an application send traffic to Clash by themselves: the browser must use the system proxy, a manually configured proxy, or a suitable TUN route.
Open “Connections” while reloading the ChatGPT page or sending one new message. Find the request’s destination hostname, matched rule, and outbound. If the entry says DIRECT, inspect the rule that matched it and the order of rules above the final MATCH rule. If the request uses a proxy group, open that group and verify which node is actually selected. A group name such as “Auto” or “Select” is not proof that a working node is in use.
Use the hostname shown in the connection log rather than guessing at a list of domains. The main page, authentication flow, static resources, and user-uploaded content may use different hostnames. A broad rule that covers only one hostname can make the landing page work while login or message generation still fails. Conversely, adding a very broad proxy rule may route unrelated traffic through the node and make diagnosis harder.
- If no matching request appears: Check whether the browser has an extension that overrides the system proxy, whether the system proxy is enabled, and whether TUN mode is needed for an app that ignores system proxy settings.
- If a request appears as DIRECT: Check rule order, rule-set health, and the actual destination hostname. Add or adjust only the narrowest rule that your configuration and network policy allow.
- If a request uses a node but times out: Test another available node, then check whether the original node can reach other sites. Record the result before changing DNS or core settings.
- If the connection is rejected immediately: Check the node’s credentials, protocol support, expiry, and the core log. A local port error and a remote node error are different problems.
Do not treat latency-test results as proof that ChatGPT is reachable. A delay test may use a different URL, request type, DNS result, or route than a real browser connection. The live connection entry and its error are more useful evidence.
Run a controlled test before editing the configuration
This step-by-step check helps separate local proxy problems from ChatGPT-specific routing. It is intentionally performed in the middle of the troubleshooting process: first identify the symptom, then use one test to collect comparable evidence, and only afterward decide what to change.
- Confirm the local endpoint. In the client’s “Settings” or “Ports” page, note the actual HTTP, SOCKS, or mixed port. The example below uses HTTP on
127.0.0.1:7890; port 7890 is common, not guaranteed. Do not substitute the controller port, which is for management rather than web proxying. - Check that the core is listening. Keep the client open and confirm there is no startup error or port conflict. If your client uses another local port, replace 7890 in the test. A connection refused error at this stage points to the local listener, not the ChatGPT node.
- Test an unrelated HTTPS website through the local proxy. In a terminal, run the command below. It asks curl to use the local HTTP proxy; it does not change the system proxy or send ChatGPT account credentials.
- Test the ChatGPT website through the same endpoint. Compare the result with the unrelated site. A response status can vary by service, region, or request method, so the useful information is whether the proxy tunnel and TLS connection complete and whether a response is returned.
- Inspect the matching connection entry. While each command runs, look in Clash’s “Connections” page for the hostname, matched rule, outbound, and duration. If the command fails, compare its error with the client’s log at the same time.
- Change one variable only. If the unrelated site works but ChatGPT does not, test one alternate node or correct one verified rule. Repeat the same test and note whether the error changes.
curl -x http://127.0.0.1:7890 -I https://example.com/
curl -x http://127.0.0.1:7890 -I https://chatgpt.com/A command-line test is a diagnostic, not a complete browser simulation. It may not use the browser’s cookies, extensions, DNS-over-HTTPS settings, or authentication session. If curl works while one browser fails, focus on that browser’s proxy settings, extensions, secure DNS configuration, and cached site data rather than changing every Clash rule.
Check DNS and how the browser or app reaches Clash
DNS problems can look like proxy failures. A browser may resolve a hostname before sending it to a proxy, or it may use its own secure DNS resolver; the exact behavior depends on the browser, operating system, proxy type, and configuration. Clash can also resolve names using its configured DNS settings. If the browser and core resolve the same hostname differently, one request may reach a different address or fail before it reaches the intended route.
Start with evidence from the client. Check the DNS and connection logs around the failed request, if available. Note whether the error is a name-resolution failure, a connection timeout, or a TLS error. These are not interchangeable: changing DNS is unlikely to fix a proxy that is not listening, and changing the node will not correct a hostname misspelled in a rule.
- Check the application’s proxy path: Desktop browsers commonly follow the operating system proxy, but extensions and browser-specific settings can override it. Terminal programs may instead need
http_proxyorhttps_proxyenvironment variables. Android and iOS clients generally route traffic through a VPN-style local interface rather than desktop system-proxy settings. - Check TUN only when appropriate: TUN mode can capture traffic from applications that do not honor a system proxy, but it requires the relevant service or VPN permission and correct routing. Confirm that the client reports TUN as active before concluding that all device traffic is being captured. Avoid enabling TUN and changing system-proxy settings simultaneously during a test.
- Check DNS settings as a controlled change: Record the current DNS mode and resolver values before testing. If you make a temporary adjustment, change only the setting relevant to the observed failure, reconnect, and repeat the same request. Do not copy a DNS recipe from another client without confirming that its fields are supported by your core.
- Check browser privacy and extensions: Temporarily compare with a clean browser profile or another browser. A proxy extension, privacy filter, secure DNS option, or content blocker can prevent one supporting request from completing even when the main site loads.
- Clear site data only after collecting evidence: If the page and network requests work but a session loops or displays stale errors, sign out if possible and clear site data for the affected site. This can remove cookies and sign-in state, so do not do it as the first step in a network diagnosis.
If the client shows a hostname routed through a proxy but its DNS lookup fails, compare the active DNS configuration with the core’s supported fields and recent logs. If the hostname resolves but the TCP or TLS connection times out, continue with node and network checks. Avoid disabling certificate validation or installing an unknown certificate to make a page load; that weakens security and does not diagnose the underlying route.
Interpret the error and choose the next safe change
Timeouts are symptoms, not a diagnosis. A timeout before a connection entry appears suggests the application may not be using Clash, or that name resolution failed outside the core. A connection entry that waits and then times out suggests the request reached the core but did not complete through the chosen route. A quick refusal often indicates a closed port, an unavailable node, or a remote service actively rejecting a connection. A TLS handshake error points to a different stage than a DNS lookup failure.
| Observed result | What it suggests | Next check |
|---|---|---|
| No connection record in Clash | The app may not be using the proxy, or it may fail before proxying | Compare browser proxy settings, system proxy status, TUN status, and DNS behavior |
| Connection record routes to DIRECT | A rule or mode selected a direct outbound | Read the matched rule and check rule order and rule-set update status |
| Proxy route shows timeout | The selected node or a network path may be slow, blocked, or unstable | Repeat with one other node and compare the same hostname and time window |
| DNS resolution error | The hostname could not be resolved by the resolver used for that request | Check the client’s DNS logs and whether the browser uses a separate resolver |
| TLS or certificate error | The connection reached a later stage but secure negotiation failed | Check device time, network interception, core logs, and whether the error repeats on another network |
Test a different node only after confirming that the request is routed through a proxy. Choose an available node supported by your configuration, then retry the same page or command. If one node works and another repeatedly fails, the issue is likely specific to the route or node; report the affected node and timestamps to the service provider without exposing credentials. If every node fails only on the current Wi-Fi network, compare with another network you are authorized to use. A network administrator, firewall, or upstream provider may restrict connections independently of Clash.
Do not repeatedly refresh, rotate nodes, clear all browser data, and rewrite DNS settings at the same time. That makes the outcome impossible to interpret and can trigger account security checks or service rate limits. If the same failure persists across a clean browser test, a second network, and multiple otherwise working nodes, retain the error details and check for service-side incidents. Account access, regional availability, organization policies, and the service’s current requirements are separate from proxy configuration; follow applicable laws, service terms, and network policies rather than attempting to evade access controls.
Once the issue is resolved, remove temporary diagnostic rules and restore any settings that did not help. Keep a short record of the working mode, selected group, relevant rule, core version, and local port. This makes later updates easier to troubleshoot without turning a temporary workaround into a permanent, overly broad configuration change.