On this page
The error on the page determines which layer to inspect
When ChatGPT or Claude will not open, first record the exact page message. Endless loading, ERR_TIMED_OUT, and 403 Access Denied are different failures; 401, 429, and 5xx likewise point to authentication, rate limits, or server errors. Writing only “doesn't work” makes every later step a guess.
Start by categorizing the page result this way
| 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 |
A browser reaching the home page proves only that the main document arrived. Scripts, images, and sign-in components may come from other static-resource domains, while sign-in redirects, file uploads, and streamed model responses create separate requests. When only the shell appears, use Connections to verify that these resources and model requests use the same stable outbound route instead of substituting another website as the test.
Pin one outbound route and preserve a comparable failure state
Create a reproducible test
Pin 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.
If the sign-in page repeatedly redirects back, focus on whether the session was established
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.
Information to preserve for sign-in issues
- The exact page and button where the loop occurs
- Whether a private window produces the same result
- Whether the failed request returns 401, 403, or timeout
- Whether the same fixed outbound route is used before and after sign-in
Access Denied cannot be solved by adding another proxy layer
An explicit 403 or Access Denied usually means the request reached the website and was rejected. Review the reason on the page, account status, regional restrictions, service availability, and whether the current outbound route complies with the service terms. This is a different layer from a DNS timeout or closed port.
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.
If short pages work but long responses stop, test connection persistence
A model response is a continuously returned data stream. A node completing one latency probe does not prove that it can sustain a connection for dozens of seconds. Use a slightly longer but repeatable prompt, observe the termination reason in Connections when it stops, and disable automatic switching so the outbound route does not change mid-response.
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.
timeout appears when the response stops
Compare another fixed node and another network to distinguish the node's outbound route from the local network.
The policy group automatically switches nodes at the moment of interruption
Use select to pin the outbound route during troubleshooting, then tune health checks after it is stable.
The page reports 429
Review account quota and rate-limit documentation; more benchmarking will not remove the limit.
Every user receives 5xx at the same time
Check official service status and retest after the upstream recovers.
If the web app works but the desktop app or API does not, determine whether the process reads the system proxy
Browsers normally honor the Windows or macOS system proxy, while terminal curl, an SDK, and some desktop apps may use their own network settings. If Connections shows no record for the same API request, it has not entered Clash, so switching nodes is meaningless.
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.comUse one short message to confirm that the request completes
Return to a fixed node in Rule mode, complete one sign-in, and send one short message. Connections should show the requests involved, the page should no longer return the original error, and the response should complete.
If it still fails, continue according to the symptom: no connection record means inspect traffic capture; DIRECT means inspect rules; timeout means compare nodes and networks; 401, 403, or 429 means investigate the server response.
After one short message completes, restore url-test or fallback. If the issue returns with the automatic group, you now have a clear comparison: the account and rules did not change; outbound selection did.