Fix ChatGPT Access Issues With Clash: Timeout and Login Checks

Separate the symptom from the cause before changing settings

ChatGPT failing to open through Clash can mean several different things: the browser is not using the proxy, a rule sends the request to the wrong route, the selected node cannot complete the connection, DNS resolution is failing, or the page loads but the sign-in flow is blocked. Treat “the page does not work” as a symptom, not as evidence that the subscription or client is broken. The goal is to identify the first point where the request stops.

Start by writing down what happens and when. Does chatgpt.com stay blank, show a connection timeout, display a Cloudflare check that never finishes, or load the page but reject a sign-in? Does the same account work in another browser or on another network? Can other HTTPS sites open through the same node? These distinctions help separate a general proxy problem from a ChatGPT-specific route or browser session problem.

Menu names differ across Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, and other clients. The underlying checks are similar, but do not assume that a control or core feature exists in every version. Note the client and core versions, active profile, current proxy mode, selected node, and the approximate time of a failed attempt. Avoid changing the subscription, DNS, browser, and node at the same time; doing so makes the result difficult to interpret.

• Only ChatGPT fails: Check domain rules, node reliability, DNS, and the browser’s sign-in session.
• Most HTTPS sites fail: Check whether traffic reaches Clash, whether the local port is correct, and whether the node can establish connections.
• The page loads but login fails: Check the authentication flow, cookies, browser extensions, system time, and whether related sign-in requests use a consistent route.
• The problem comes and goes: Compare connection records and logs at the time of failure; a successful test performed earlier does not prove that the node is healthy now.

Step 1: Verify proxy mode and the browser’s actual route

Selecting a proxy node does not necessarily send browser traffic through that node. In a common desktop setup, System Proxy tells supported applications to use the local proxy listener. TUN mode uses a virtual network interface to capture more system traffic, including traffic from applications that ignore system proxy settings. TUN may require elevated permissions and can interact with other VPN or traffic-capture software. Start with one route at a time rather than enabling multiple interception methods together.

1. In the Clash client, confirm that the core is running and check the displayed mixed port or HTTP port. Use the port shown in the active configuration; do not assume it is 7890. A sample local address might be 127.0.0.1:7897.
2. For a system-proxy test, enable the client’s System Proxy control and check the operating system’s proxy settings. The address and port should match the client’s listener. If a browser proxy extension is enabled, disable it temporarily so it cannot override the system setting.
3. If testing with TUN, confirm that it is enabled and that the core has permission to create or manage the interface. Temporarily turn off other VPNs, proxy clients, or network-filtering tools that may compete for routes.
4. Open the client’s Connections or equivalent panel, then reload https://chatgpt.com/. Look for the request and inspect the rule and outbound shown for it. Check the Logs panel at the same time for connection, DNS, or TLS errors.

A missing connection entry can indicate that the browser is bypassing the proxy, but it is not conclusive on its own: short-lived entries may disappear quickly, and some clients filter or group records. Repeat the page load while watching the panel, then compare it with the logs. If the browser is using a manual proxy, make sure the proxy type matches the listener: a mixed port can accept common HTTP and SOCKS requests, while a SOCKS-only listener must be configured as SOCKS. The controller port is for client management, not ordinary web traffic.

Test the local proxy directly

A command-line request can help bypass browser settings. Replace 7897 below with the actual local mixed port. In Windows PowerShell, use curl.exe explicitly; the name curl may otherwise resolve to a PowerShell command with different options.

curl.exe -v --max-time 20 --proxy http://127.0.0.1:7897 https://chatgpt.com/ -o NUL

On macOS or Linux, use -o /dev/null instead of -o NUL. The command is a connectivity check, not a login test. An HTTP response such as a redirect or access-denied status can still show that a connection reached a server; a timeout, failed name lookup, or inability to connect to the local proxy points to a different stage. Do not share verbose output without checking it for private data.

Step 2: Check rule mode, rule matching, and the selected outbound

In Rule mode, Clash evaluates the active rules in order and sends each request to the outbound selected by the first matching rule. A page may make requests to more than one hostname, so checking only the address bar is not enough. The main page, static assets, API calls, account sign-in, and verification services can use separate domains. A rule for one hostname may therefore send some requests through a proxy and others directly.

Open the Connections panel immediately after a failed attempt. Find entries associated with the page load, then check the matched rule, rule provider if shown, and outbound. If a relevant request is marked DIRECT when it should use a proxy, inspect the active rule set and its order. If it uses a proxy group, confirm which node the group selected. An entry for the main page alone does not prove that every login or API request used the same route.

For a controlled test, switch temporarily to Global mode if the client provides it, select a known-working proxy group or node, and reload the page. Global mode routes connections through the selected proxy rather than relying on domain rules, but it still depends on the browser reaching the local proxy and the node being usable. If this test works while Rule mode does not, investigate rule matching rather than replacing the whole profile. Return to the original mode after testing.

Some configurations support custom rules such as DOMAIN or DOMAIN-SUFFIX. Do not paste a large list of guessed domains into a live profile: rule syntax, provider data, and service endpoints can change, and a broad rule may affect unrelated traffic. If editing rules, make a copy first, place the test rule before any broader matching rule, validate the configuration with the client’s supported core, and verify the resulting outbound in Connections. Preserve existing provider rules unless you know how the profile is assembled.

Step 3: Compare node reliability and DNS behavior

A node latency test measures a particular probe at a particular time. It does not guarantee that the node can reach every service, sustain a longer HTTPS session, or handle the route currently selected by a proxy group. Conversely, a failed probe may use a test URL that is blocked or unavailable even when other connections work. Use the test as one piece of evidence, then check the actual request and client logs.

1. Keep the same browser, mode, and URL. Select one node that has recently worked for other HTTPS sites and load ChatGPT once.
2. Repeat with a second node. If only one node fails while the same local proxy setup works with another, the issue is likely associated with that node or its route.
3. Check whether an automatic group, fallback group, or load-balancing group is changing the outbound between attempts. For diagnosis, choose a specific node manually if the client allows it.
4. Read the log entry at the failure time. Distinguish a name-resolution error from a connection timeout, TLS handshake problem, or remote refusal; each points to a different layer.

DNS checks are useful when logs show lookup failures, when a domain resolves inconsistently, or when the page behaves differently after changing networks. In mihomo, DNS settings such as nameserver determine upstream resolvers, while enhanced-mode determines whether applications receive real addresses or fake-IP mappings. TUN DNS interception, system DNS, and browser secure DNS are separate paths. Editing a resolver list will not fix a browser that bypasses the proxy, and changing a node will not correct a malformed DNS setting.

For a comparison, use the same network and the same test sequence. First confirm whether a normal domain resolves through the operating system. Then review the Clash DNS and TUN settings actually in use, including any client overrides. If the browser has its own Secure DNS or DNS-over-HTTPS option, temporarily disable that feature only for a controlled test, or ensure it is configured consistently with the network you intend to test. Restore the original setting afterward.

Do not switch repeatedly between fake-ip and redir-host as a first response. Those modes change address handling and may affect existing connections or application behavior. If a DNS change is justified, back up the profile, change one setting, restart or reload the core if required by the client, and retry the same hostname. Record whether the failure changes from lookup timeout to connection timeout; that difference is more informative than simply noting that the page still does not open.

Step 4: Troubleshoot sign-in and apply a controlled test sequence

If the ChatGPT page opens but authentication does not complete, stop changing DNS until you have checked the browser and the login requests. A stale cookie, blocked third-party storage, an extension that modifies requests, or a browser profile issue can interrupt sign-in even when the proxy connection is healthy. System clock errors can also interfere with certificate validation and time-sensitive authentication.

1. Confirm the computer or phone has the correct date, time, and time zone. If the device clock is substantially wrong, correct it and retry before changing proxy settings.
2. Open a private or incognito window with extensions disabled where possible. Sign in again and observe whether the result changes. This is a comparison test, not a requirement to keep using a private window.
3. Check that the browser allows the storage and cookies required by the sign-in flow. If you clear site data, do so only for the relevant service and understand that it will sign you out; avoid clearing all browser data as an initial troubleshooting step.
4. During the login attempt, inspect Clash Connections for the requests that appear and compare their rule and outbound with the main page. Check Logs for timeouts or DNS errors at the same moment.
5. Try a second browser using the same node and mode. If one browser works and the other does not, focus on browser settings, extensions, or its profile rather than rebuilding the Clash configuration.

Use this sequence to isolate the cause without changing several variables at once: first verify that the browser reaches the local listener; next confirm that Connections records the request; then test a known-working node in Global mode; compare it with Rule mode; and finally investigate DNS or browser sign-in settings only when the evidence points there. After each change, reload the same URL and note the result. If the page works in Global mode but not Rule mode, restore Rule mode and adjust only the relevant rule. If all nodes fail but ordinary websites work, collect the time and non-sensitive log details before contacting the node or service provider.

When testing from another network, keep the device, browser, and node selection as consistent as possible. A mobile hotspot can help determine whether a home router or ISP path is involved, but changing networks also changes DNS and may affect node reachability. Record that as a separate comparison rather than treating it as proof of a single cause. If the problem resolves without a configuration change, note the time and test again later before editing a working profile.

When sharing diagnostics, provide the client name and version, core name and version, operating system, proxy mode, approximate failure time, and the specific error text. Redact subscription URLs, node credentials, account details, cookies, tokens, and public IP addresses if they are not needed. Do not publish a full configuration unless you have checked every line for secrets and private endpoints.