1. Identify Where the Timeout Occurs
When ChatGPT will not load while Clash is running, “timeout” is a symptom, not a diagnosis. The browser may fail to reach Clash’s local proxy port, a routing rule may send the request to the wrong outbound, the selected node may not reach the destination, or DNS may return an unusable address. A site can also load its main page while a separate API or static-resource request fails. Changing several settings at once makes these cases harder to distinguish.
Start by noting what you see and when it happens. A browser error before any page content appears differs from a blank conversation after the interface loads. A page that loads but cannot sign in may point to a failed API request, a browser extension, or a session issue rather than a basic proxy connection. Record the time, the client and core names and versions, the active mode, the selected proxy group, and the exact error text. Do not include subscription URLs, passwords, cookies, or authorization headers in screenshots or support messages.
| What you observe | First place to check | What it can tell you |
|---|---|---|
| ChatGPT and other sites all time out | Local proxy setting, Clash status, and active node | The issue may be broader than ChatGPT-specific routing. |
| Other proxied sites work, but ChatGPT does not | Connection logs and rules for the failing hostname | A domain-specific rule or destination-specific connection failure is more likely. |
| The page opens, but sign-in or conversation requests fail | Browser network errors and logs for API or resource hostnames | Different parts of the service may be using different connections. |
| The same node works in one app but not another | Whether the affected app follows the system proxy | Traffic capture may differ even though the node itself is available. |
2. Check Proxy Mode, Rules, and the Selected Policy
Clash mode and traffic capture answer different questions. The system proxy or TUN determines how an app’s connection reaches the core; rule, global, or direct mode determines what the core does with a connection it has captured. Selecting global mode cannot help a browser that bypasses Clash, and switching to rule mode does not guarantee that a particular hostname is sent through a proxy.
For a first comparison, confirm that the client is running and that the active configuration is selected. In rule mode, inspect the connection list or logs while refreshing ChatGPT. Look for the hostname shown in the failed request, the matched rule, the policy or proxy group, and the resulting outbound. The domain may be different from the address in the browser bar: the page, API, login flow, and static assets can use separate hostnames. Do not assume that one rule for the main website covers every request.
Check the selected policy as well as the rule. A rule can point to a group whose current choice is DIRECT, an unavailable node, or another group. If the log shows a proxy group, open that group and confirm its current selection. If it shows DIRECT, determine whether that result is intentional. If there is no relevant connection in Clash at all, focus first on traffic capture, the system proxy setting, or whether the app is using its own proxy configuration.
Use global mode as a short diagnostic test
Temporarily select global mode and choose a known working proxy policy, then open a new private window or restart the browser. If ChatGPT works in this test but not in rule mode, the comparison points toward rule order, the matched policy, or the selected group—not necessarily a defective node. Restore rule mode after testing. Global mode is a diagnostic, not a reason to leave all traffic on one policy indefinitely.
If it still fails in global mode, check whether the browser connection appears in Clash and which node handles it. Try one other node from the same subscription, preferably one whose ordinary HTTPS connectivity is known to work. A low latency number only measures a particular test target and does not prove that the node can establish a usable connection to every service. Avoid repeatedly switching nodes while a page is still making requests; close or reload the page between comparisons.
3. Run a Controlled Check in the Middle of Troubleshooting
Use this sequence to separate a routing problem from a node, local proxy, or DNS problem. Menu labels differ across Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Android clients, and other Mihomo-based interfaces, so use the client’s connection, proxy, and log views rather than relying on one exact menu path.
- Confirm the client is active. Check that the core is running, the intended configuration is selected, and the client reports no configuration parse error. Confirm the local HTTP, SOCKS, or mixed port shown by the client; do not assume it is always
7890. - Check the browser’s route into Clash. If you use the system proxy, confirm that the operating system shows the proxy enabled and that the browser has not been set to bypass it. Then refresh the site and check whether a new connection appears in Clash’s log. If the browser has a separate proxy extension or manual setting, temporarily disable conflicting settings for a clean test.
- Test one hostname and one node. In rule mode, note the policy selected for the connection. If the route is unclear, briefly use global mode with one known working node. Do not change DNS, TUN, and the node at the same time.
- Repeat with a fresh connection. Close the affected tab, open a new one, and test again. Existing browser connections can persist after a mode or node change, so a page that was already open is not always a fair comparison.
- Restore the normal setup. Return to rule mode and your intended group selection. Keep TUN off unless you need to test whether the browser was bypassing the system proxy.
On a desktop system, you can optionally test the local HTTP proxy from a terminal, replacing the port with the one displayed in your client:
curl -x http://127.0.0.1:7890 -I --connect-timeout 10 https://chatgpt.com/This checks whether a command-line request can connect through that local proxy and receive an HTTP response. It does not verify browser cookies, sign-in, every API hostname, or the quality of every page resource. A redirect or an HTTP response other than 200 still indicates that a network response was received; interpret the result alongside the browser and Clash logs. If the command cannot connect to the local address, recheck the client status and port before editing domain rules.
4. Verify Node Reachability and DNS Resolution
If Clash captures the request and routes it to a proxy, inspect the connection result. A timeout while connecting to a node, a failed TLS handshake, and a remote server response are different stages. Check the client’s log for the associated error and timestamp. If multiple unrelated destinations fail through one node, the node or the network path to it may be unavailable. If other sites work through the same node but a specific ChatGPT request fails, compare another node before rewriting the entire configuration.
DNS adds another variable because the browser or core must resolve hostnames into addresses. Check which DNS mode is active and whether the failed hostname appears to resolve. A DNS failure can look like a connection timeout, but changing DNS servers without evidence can create new problems, such as inconsistent answers or blocked upstream queries. If your client uses Mihomo DNS features such as fake-IP mode, use its connection and DNS logs to see what was returned and whether the request was associated with the expected domain. Do not paste a new DNS block from an unrelated configuration without checking that your core supports its fields.
When testing DNS, keep the experiment narrow. Compare the result for the hostname shown in the log, not just the main page’s hostname. Check that the configured upstream can be reached through the intended route and that DNS requests are not being sent into a proxy loop. If name resolution succeeds but the outbound connection fails, focus on the selected node, rule, or remote path instead. If the hostname is absent from the log, first determine whether the browser’s DNS or connection is bypassing the core.
| Log or test result | Likely next check | Avoid assuming |
|---|---|---|
| No matching connection appears | System proxy, browser proxy, TUN capture, and client status | That a routing rule is wrong when the core never received the request. |
| DNS lookup fails or returns no usable result | Resolver status, upstream reachability, and the exact hostname | That changing to an arbitrary public resolver will solve the route. |
| Node connection or handshake times out | Node availability and a comparison with one other node | That the browser cache or a domain rule caused a transport failure. |
| Request succeeds in global mode only | Matched rule, group selection, and rule order in rule mode | That every hostname used by the page follows the same policy. |
5. Test TUN Only When Capture Is the Suspect
TUN is useful as a controlled test when the browser appears to bypass the system proxy or when the client log contains no corresponding connection. It uses a virtual network interface and operating-system routes to capture eligible IP traffic; it is not a proxy node and does not fix a failing outbound connection. TUN also does not guarantee that every app or destination is captured: routing exclusions, permissions, DNS handling, and platform behavior matter.
Before enabling it, close other VPN or network-filtering applications that might conflict, check the client’s TUN permission status, and note the existing route and DNS settings. Enable TUN using the client’s supported controls, authorize the system prompt if required, and test one fresh browser connection while watching the log. If the request now appears and succeeds, the original issue may have been that the browser was not using the system proxy. If it appears but still times out, TUN did its capture job; continue investigating the matched rule, DNS result, and selected outbound.
Turn TUN off after the comparison if it is not part of your normal setup. On Android, the VPN permission is managed by the operating system and generally only one VPN-style service can be active at a time. On desktop systems, administrator permission, other virtual adapters, security software, or custom routes can affect behavior. If enabling TUN causes other network problems, restore the previous state rather than changing routes manually without understanding their effect.
Keep the final change small and verifiable
Once the failing stage is identified, make one targeted correction: select an available node, adjust the policy group used by the matching rule, fix a confirmed rule-order mistake, or correct the local proxy setting. If only one hostname is consistently misrouted, use the hostname observed in the logs and place a specific exception above broader rules where appropriate. Service hostnames can change, so avoid treating any short domain list as a permanent, complete inventory. Do not replace the whole subscription or add broad rules unless the evidence supports doing so.
Finally, retest the page and its sign-in or conversation function, not just the first document response. Confirm that ordinary sites still follow their intended policies, restore any temporary global or TUN test settings, and check the logs once more. If the same error persists across nodes and networks while other proxied destinations work, preserve the exact timestamp and redacted error details; the remaining cause may be upstream service availability or account-side behavior, not a local Clash setting.