Fix ChatGPT Not Working With Clash: Timeout Troubleshooting

Start With the Exact Symptom

When ChatGPT stops working while Clash is running, the visible error is often too general to identify the cause. A page that keeps loading, a connection timeout, an empty response, a login loop, and a page that opens but cannot send messages can all come from different layers of the connection. Before changing several settings at once, classify the failure first. That gives you a much shorter troubleshooting path and prevents a working part of the setup from being broken accidentally.

There are four layers to check: the local Clash client, the selected proxy node, the routing rule, and DNS or system-level traffic capture. A node may be reachable while the target service is routed to DIRECT. A correct rule may still fail because the node is overloaded. A browser may work in system proxy mode while another application bypasses it completely. TUN mode can solve that bypass, but it also introduces route, permission, and DNS variables that need to be checked separately.

Check Proxy Mode and the Selected Node

Open Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, or another mihomo-based client and confirm that the core is actually running. The interface may remain open even when the core has stopped, failed to load the profile, or lost permission to create a TUN interface. Check the dashboard for a running status, then check the active profile and the proxy group used by the default rule.

For a browser test, start with Global mode or the client’s equivalent. Global mode sends all captured requests to the selected proxy group, so it temporarily removes rule matching from the equation. If ChatGPT works in Global mode but not in Rule mode, the node is probably usable and the problem is routing. If it fails in both modes, continue with node and DNS checks instead of adding random domain rules.

Next, open the proxy group and test individual nodes. A low latency number alone is not proof that a node can maintain a long HTTPS connection. The test may only measure a short TCP or HTTP request, while the service needs stable TLS traffic and sometimes long-lived connections for streaming responses. Look at timeout rate, recent test time, geographic location, and whether the node repeatedly disappears from the group.

• Test at least three nodes. Choose nodes from different regions or providers when possible. If only one node fails, replace the node rather than rewriting the whole configuration.
• Prefer stability over the smallest ping. A node with slightly higher latency but no packet loss is usually better for login, streaming output, and file requests.
• Refresh the profile when necessary. An expired subscription, deleted node, or partially updated proxy group can leave the interface showing entries that no longer work.
• Check the proxy protocol. The mihomo core supports many protocols, but the client version and imported profile must support the particular fields used by the node. Unsupported transport options can cause an immediate connection failure.
• Disable competing VPN software. Another VPN, firewall filter, or corporate security client may capture the same traffic and create a loop or refuse the connection.

After selecting a stable node, test both the service page and an unrelated site that should use the same proxy path. If the unrelated site works but the ChatGPT page still times out, do not conclude that the node is unusable. The target service may require more complete routing or may reject a particular exit address.

Inspect Rules Before Adding More Rules

In Rule mode, Clash evaluates rules from top to bottom. The first matching rule determines the outbound policy, and later rules cannot override it. This is the most common reason a user adds a correct-looking proxy rule but sees no change: an earlier rule already sends the request to DIRECT, REJECT, or another group.

Use the client’s Connections, Requests, or Logs view while opening the page and sending a harmless test message. Find the requests associated with the service and record the destination, matched rule, and final outbound. The useful question is not simply “is Clash enabled?” but “which rule handled this request, and which node or policy received it?”

A narrow domain rule is safer than a broad keyword rule. If your provider supplies a maintained service rule set, use that set according to its documentation instead of copying a long list from an unknown source. Service access may involve the main web domain, authentication endpoints, API endpoints, static assets, media delivery, and telemetry or CAPTCHA resources. Routing only the landing page is therefore often incomplete.

# Illustrative structure only; replace SERVICE-GROUP with your own policy name
rules:
  - DOMAIN-SUFFIX,service.example,SERVICE-GROUP
  - DOMAIN-SUFFIX,auth.example,SERVICE-GROUP
  - MATCH,Default

The domains in this example are placeholders. Do not paste them into a live profile and expect them to work. The important points are rule order, specific suffix matching, and using the same proxy group for related requests. Avoid DOMAIN-KEYWORD unless you understand its wide matching scope; a short keyword can accidentally proxy unrelated sites or cause an unexpected policy loop.

Hands-On Troubleshooting Sequence

Use the following sequence in the middle of the diagnosis. It is designed to isolate one variable at a time and works with most desktop mihomo clients. Mobile clients expose fewer logs, but the same order still applies.

1. Close the ChatGPT tab or application, stop other VPN and proxy tools, and restart the Clash core. Confirm that the intended profile is active and that the proxy group contains available nodes.
2. Switch to Global mode, select a stable node manually, and open the service again. If it now works, switch back to Rule mode and continue with the rule inspection rather than keeping Global mode permanently.
3. Open the connection log and clear old entries. Reload the page, sign in if needed, and attempt one normal request. Record whether each important request is marked DIRECT, REJECT, or the intended proxy group.
4. If requests are missing from the log, verify the browser or application proxy settings. Enable TUN only after confirming the client has permission, then restart the core and test again.
5. If requests appear but DNS fails, change the DNS configuration to a known working setup supported by your profile. Confirm that the resolver can reach its upstream and that fake-IP or redir-host behavior is consistent with the client.
6. Test two or three different nodes. Keep the node that completes page loading and a normal message request without repeated reconnects; do not judge only by the first page load.
7. Return to Rule mode, add or correct the narrow service rules near the top of the rule list, reload the profile, and repeat the same request. Confirm the matched rule in the connection detail panel.
8. Restore any unrelated settings you changed during testing, then test a second browser or application. This confirms that the fix is not limited to a cached session or one application’s proxy implementation.

Clear browser site data only after the network path is confirmed. Deleting cookies too early can create a new login challenge and make the original timeout harder to recognize. Also avoid repeatedly refreshing the login page during testing, because security checks may temporarily restrict repeated attempts even when Clash is configured correctly.

DNS, TUN, and Applications That Bypass the Proxy

DNS errors can look exactly like routing errors. If Clash resolves a service domain through a local resolver that returns an unreachable or unsuitable address, the rule may be correct but the connection still times out. In mihomo, the DNS module can use nameserver, fallback, default-nameserver, and an enhanced mode such as fake-ip or redir-host. These fields must work together; copying a DNS block without understanding the mode can create startup failures, slow resolution, or inconsistent answers.

When fake-IP mode is enabled, a domain can appear in logs with an address from the reserved fake-IP range, commonly 198.18.0.0/16. That address is an internal mapping, not the real server address. If an application treats it as a literal public IP, add the appropriate fake-IP filter or use a compatible DNS mode. With redir-host, Clash returns real addresses, but rule matching and DNS interception may behave differently.

Check the following points:

• Make sure the DNS listener is enabled and not competing with another local resolver on the same port.
• Use a reachable default-nameserver for bootstrapping encrypted DNS hostnames; it should contain resolver addresses rather than encrypted URL forms.
• Review nameserver-policy or equivalent policy rules if certain domains are forced to an unsuitable resolver.
• Flush the operating system DNS cache after changing enhanced mode. Existing cached answers can make a correct configuration appear ineffective.
• Check whether the browser has its own secure DNS setting enabled. It may send DNS requests outside the path managed by Clash.

System proxy mode only changes applications that honor the operating system’s HTTP or SOCKS proxy setting. It does not automatically capture every TCP or UDP connection, and it does not guarantee that DNS requests use Clash. TUN mode creates a virtual network interface and routes system traffic through the mihomo core, which is useful for applications that ignore system proxy settings. It may require administrator privileges on Windows, a network extension approval on macOS, or a VPN permission on Android.

Enable TUN only after checking the client’s permission prompts and route settings. Common options include auto-route, auto-detect-interface, and dns-hijack. If TUN is enabled but the operating system still uses another VPN interface, traffic can loop between adapters. Temporarily disable other virtual interfaces, restart Clash, and confirm that the TUN interface is receiving connections in the log.

When the Basic Fixes Do Not Work

If the page still times out after Global mode, several nodes, correct routing, and a verified DNS path, separate service-side rejection from local configuration. Test the same node with another browser, then test another device on the same network. If every device fails through the same node but other nodes work, the exit address may be rate-limited, blocked, or overloaded. If only one device fails, focus on its firewall, browser extensions, DNS cache, or TUN route table.

Inspect the Clash log at an appropriate level. A connection that ends during DNS lookup points to resolver or policy problems. A TLS handshake timeout suggests the node, transport, MTU, or exit network. A connection that completes TLS but stalls while receiving data can indicate an unstable route, an application-layer restriction, or a node that cannot maintain long-lived connections. Do not leave debug logging enabled permanently, because it can generate large logs and expose domains or connection metadata locally.

Also verify the system clock. TLS certificates and authentication tokens can fail when the clock is substantially wrong. Check that the profile is not expired, that the subscription has not reached its traffic or time limit, and that the client is not silently using an old configuration after an update. On desktop systems, temporarily test with a clean profile containing one node, one proxy group, a small number of rules, and a simple DNS block. A minimal profile is often faster to diagnose than a large provider configuration with many rule providers and scripts.

Once the issue is fixed, keep the final configuration conservative: a stable node group, narrowly scoped service rules, one consistent DNS strategy, and TUN enabled only when an application truly needs full traffic capture. Export or back up the working profile, but remove subscription credentials before sharing a diagnostic file. If you need to request support, provide the client name and version, mihomo core version, operating system, proxy mode, matched rule, and a short sanitized log excerpt rather than posting the complete profile.