On this page
When the ChatGPT or Claude home page opens but login or sending a message fails, reloading the home page will not explain the failure. Match the failed action’s status code with the Clash records to distinguish requests that never reach the proxy, use the wrong outbound connection, or reach the service but are rejected. Keep a fixed node during testing, then check login sessions and sustained responses separately so changes in the outbound connection do not confuse the results.
What Do Timeouts, 403 Responses, and Interrupted Replies Mean?
Record the exact error, when it appeared, and what you were doing. Distinguish a failed login, blank page elements, and an interrupted response instead of recording them all as “cannot connect”; they may come from different requests.
Error Messages and Where to Investigate
| Observed behavior | First interpretation |
|---|---|
| The page shell appears, but icons, buttons, or sign-in components are blank | Static-resource domains may use a different rule or outbound route |
| ERR_CONNECTION_TIMED_OUT / request timeout | Network path, node, or persistent-connection failure |
| 401 / Unauthorized | Sign-in state, token, or API credential |
| 403 / Access Denied | Service policy, account status, or a rejected request |
| 429 / Too Many Requests | Rate or quota limit, not node latency |
| 500 / 502 / 503 | A temporary service or upstream failure; check official status first |
| The response stops midway | Streaming connection, node switch, or network jitter |
If the page frame appears but its content does not load, inspect requests for scripts, images, and login components; these resources may come from different static-resource domains. Login redirects, file uploads, and streaming model responses also make separate requests. In Connections, check each resource and model request for the same stable outbound connection rather than testing a different web page.
Fix the Node Selection and Observe the Failed Request’s Exit
Create a reproducible test
Fix One Node in Proxies
Temporarily avoid url-test and fallback so the outbound route does not change during testing.
Keep Rule mode
Open Connections and prepare to observe the domain and rule for the failing action.
Repeat only one action
For example, click sign in, send the same short message, or upload the same small file.
Save the page state and Clash result
Record the HTTP status, connection outbound route, elapsed time, and log error.
If the failing action never appears in Connections, the browser or desktop app may not be using the current Clash. If a record appears but matches DIRECT, inspect the rules. Only when it reaches the pinned node and still shows timeout is it useful to compare another node or network.
Login Loops: Check Browser Sessions and Authentication Requests
A sign-in loop often returns to the login page after credentials are entered, or completes verification without opening the chat. Retry first in a private window in the same browser to rule out an expired session or extension interference. Do not immediately clear all site data, which also signs you out elsewhere.
Observe requests after clicking sign in. If the authentication redirect does not enter Clash, address browser proxying. If it enters and returns 401 or 403, the network reached the service; continue with the account, sign-in method, and service message. Frequent region or outbound-route changes can also span one login across several session environments, so keep a fixed node during testing.
403 Access Denied: Account, Region, and Service Restrictions
An explicit 403 or Access Denied usually means the request reached the website but was rejected. Check the reason on the page, account status, regional restrictions, supported service regions, and whether the current outbound connection complies with the terms of service. This rejection has different causes from a DNS timeout or a port that is not open.
Global mode can at most determine whether a rule sent a request to the wrong outbound route; it cannot turn a server rejection into network success. If Rule and Global return the same 403 through the same fixed node, stop adjusting Clash and address the account or service policy.
Compare Nodes and Access Networks When Long Replies Stop
Model replies keep returning data; a successful latency probe does not show that a node can sustain a connection for tens of seconds. For testing, change the policy group to select, fix one node, and use a repeatable long prompt to inspect the termination reason in Connections when the reply stops.
Test the same fixed node once on the home network and once on a mobile hotspot. If only one network interrupts, focus on that network and DNS. If both stop at a similar point, compare another protocol or node. Do not conclude from one success; repeat the same request at least two or three times.
The Website Works, but the Desktop App or API Cannot Connect
Browsers usually follow the Windows or macOS system proxy, while curl, SDK tools, and some desktop apps may use their own network settings. If the same API request produces no new record in Connections, first check whether the app uses the current proxy rather than immediately changing nodes.
Configure HTTP_PROXY and HTTPS_PROXY for command-line tools according to their documentation. Consider TUN only if you need to capture several apps that ignore the system proxy. An API response of 401 means the request reached the server; verify the API key and request format instead of expanding proxy scope.
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.com$CLASH_PORT = 7890
$env:HTTP_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:HTTPS_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.comRestore Automatic Node Selection After a Complete Reply
Return to a fixed node in Rule mode, sign in once, and send one short message. If the original problem was an interrupted long response, repeat the same long request too. Connections should show the relevant requests, the page should no longer return the original error, and the response should finish.
Restore url-test or fallback after both the short message and the originally failing request complete. If the problem returns after restoring the automatic group, the comparison is clear: the account and rules have not changed, but outbound selection has.