Identify the failure before changing the configuration

“ChatGPT does not work with Clash” describes several different failures. A browser may show a blank page, return a gateway error, remain stuck on “Loading,” reject the login request, or open the interface while every conversation request times out. These symptoms do not necessarily have the same cause. Changing the subscription immediately can hide the evidence and make diagnosis slower.

Start by separating the connection into four layers: the local Clash listener, the selected proxy node, the routing decision, and the destination-side DNS and TLS connection. If the local listener is not running, no application can reach Clash. If the listener works but the node is unavailable, all proxied destinations may fail. If only ChatGPT fails, the likely candidates become routing rules, DNS resolution, TLS negotiation, or a destination-specific restriction.

Use a private browser window only as a secondary test. It can distinguish stale cookies or extensions from network problems, but it does not prove that the proxy path is healthy. Also test a normal, non-sensitive website and one service known to require the same general network path. The objective is to establish a baseline, not to repeatedly refresh the ChatGPT tab.

Check the node, proxy group, and operating mode

A timeout is often caused by a dead or overloaded node rather than by ChatGPT itself. A node can still appear in the profile while its server is unreachable, its port is blocked, its credentials have expired, or its available bandwidth is exhausted. A latency value of N/A, a failed URL test, or repeated connection failures in the Clash log is stronger evidence than the node’s name or position in the subscription list.

Open the client’s proxy page and select a different node from the same provider. Prefer a node in another region or on a different transport when the first alternatives fail. Do not test ten nodes at once and conclude that the whole service is broken; first test one known ordinary website, then ChatGPT, and record the result. If every node fails for every destination, investigate the local client, subscription, network, or provider status. If one node fails while others work, remove that node from consideration instead of editing unrelated rules.

Next, confirm the active mode. Rule mode is normally the correct daily setting because it evaluates the configuration’s rules and sends each request to the designated policy. Global mode sends matched traffic through one selected proxy group or node, depending on the client interface. Direct mode bypasses the proxy. Names and controls differ between clients, so read the actual mode indicator rather than assuming that a selected node means all traffic is using it.

1. Set the client to Global mode temporarily and select a node that passes the client’s connectivity test.
2. Open ChatGPT and check whether the landing page, login flow, and a new conversation all complete.
3. Switch back to Rule mode and repeat the same test without changing the node.
4. If Global works but Rule fails, inspect the rules and policy group. If both fail, focus on the node, DNS, TLS, or local network.
5. Use Direct mode only as a comparison. A direct failure does not prove that the proxy is broken; it may simply reflect the network path available without the proxy.

Inspect routing rules and the actual request log

In Rule mode, the important question is not “Is a proxy selected?” but “Which policy did Clash assign to this request?” A broad DOMAIN-KEYWORD rule, an incorrectly ordered DOMAIN-SUFFIX rule, or a final DIRECT catch-all can send ChatGPT traffic outside the intended path. The first matching rule wins. Rules below that match are never evaluated.

ChatGPT’s web experience may contact several hostnames rather than a single domain. Common examples can include chatgpt.com, openai.com, auth.openai.com, api.openai.com, and challenge or content delivery domains. The exact set can change with the web application, account flow, browser, and service infrastructure. Do not copy a hostname from one request and assume it covers the entire session.

Use the Clash connection panel or live log while opening the site. Search by hostname and note four values: the requested domain, the matched rule, the selected policy, and whether the connection ends in success, timeout, reset, or DNS failure. This is more reliable than adding a large collection of guessed domains to the configuration.

rules:
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT
  - DOMAIN-SUFFIX,openai.com,ChatGPT
  - DOMAIN-SUFFIX,auth.openai.com,ChatGPT
  - DOMAIN-SUFFIX,api.openai.com,ChatGPT
  - MATCH,Proxy

The example assumes that a proxy group named ChatGPT already exists. If the group does not exist, the configuration may fail validation or the client may substitute an unexpected policy. Replace the group name with one that actually appears under proxy-groups in the imported profile.

Place specific rules above broad rules. For example, a previous DOMAIN-SUFFIX,openai.com,DIRECT entry will override a later proxy rule for api.openai.com. Likewise, a GEOIP,CN,DIRECT rule usually does not explain a domain-based failure by itself, but an IP-CIDR rule, a private-network rule, or a provider-generated rule set can take precedence. Review the complete order rather than editing only the visible custom section.

Apply a controlled repair sequence

This section is the practical runbook. Perform the steps in order and change one variable at a time. A controlled sequence preserves the distinction between a node problem and a configuration problem.

1. Confirm the local listener. In the Clash dashboard, verify that the HTTP or mixed port is enabled and note its port number. If the client uses a mixed port, do not manually configure the browser as SOCKS5 unless the client explicitly exposes a SOCKS5 listener on that port.
2. Test the selected node. Run the client’s URL or latency test, then open a simple external website. A successful latency test is not a complete guarantee, but a failed test makes ChatGPT troubleshooting premature.
3. Clear temporary application state. Close the ChatGPT tab, restart the browser, and test a private window. If the private window works, disable extensions selectively and clear site data for ChatGPT and OpenAI domains. Avoid deleting all browser data before confirming that stale state is involved.
4. Compare Global and Rule modes. Keep the same node while changing only the mode. Record whether the page, login, and message submission each work. This comparison identifies rule matching as a likely cause without requiring a new subscription.
5. Inspect the connection log. Filter for ChatGPT, OpenAI, authentication, and challenge-related hostnames. Look for a direct policy, an unexpected group, repeated retries, or a DNS error. A hostname resolving but failing to establish TLS points to a different layer than a hostname that cannot resolve at all.
6. Add narrow rules if justified. Place the required domain-suffix rules above conflicting direct rules and reference an existing proxy group. Save or create a local override rather than repeatedly modifying the provider’s remote profile if the client supports overrides.
7. Restart the core after validation. Validate the YAML first. Then reload the profile or restart the Clash core so that the revised rules, DNS settings, and proxy group are actually active. A file saved on disk is not necessarily the configuration currently loaded in memory.
8. Return to the normal operating mode. Use Rule mode after the comparison unless Global mode is an explicit requirement. Test the landing page and one message, then monitor the log for a few minutes instead of continuously changing nodes.

When a configuration contains provider-managed rule sets, use the client’s configuration preview or merged-config view if available. That view shows the effective order after remote rules, local overrides, and generated rules have been combined. Editing the source profile alone may not change the final rule order.

Resolve DNS, TUN, and transport conflicts

DNS failures can look like ordinary timeouts. If the resolver returns an unreachable address, leaks a local answer that does not match the intended proxy path, or is intercepted by another network component, Clash may never establish the destination connection. Check the DNS section of the active configuration and the DNS-related entries in the runtime log. Also check whether the browser is using its own secure DNS resolver, because browser-level DNS can bypass assumptions made about Clash’s resolver.

In fake-IP mode, Clash returns synthetic addresses and maps them back to domain names inside the core. This can improve rule matching for applications that connect by IP after DNS resolution, but it requires compatible fake-IP filtering and correct DNS handling. In redir-host mode, the real resolved address is returned instead. Neither mode is automatically better for every environment. A fake-IP filter that excludes a required domain, or a browser resolver that bypasses Clash, can create a failure that appears to be a node timeout.

For a clean comparison, temporarily keep the DNS design simple. Use a resolver configuration supported by the selected core, avoid mixing several unrelated DNS interception mechanisms, and make sure the client’s DNS hijack setting points to the correct local DNS listener when TUN mode is enabled. Exact field names vary between Clash Meta and mihomo-based clients, so validate against the core’s accepted schema rather than pasting options from an older Clash version.

TUN mode adds another possible failure point. It captures traffic at the virtual network interface and can cover applications that ignore system proxy settings, but it also depends on administrator permission, a working virtual adapter, routing-table changes, and correct DNS interception. If ChatGPT works in system proxy mode but times out only with TUN enabled, disable TUN and compare the route and DNS behavior. Check for conflicts with VPN software, endpoint security products, virtual machines, and other packet filters.

Decide whether the provider is the actual problem

Switching providers should be the final diagnostic step, not the first reaction to one timeout. Provider-side problems become more plausible when every node fails the same destination, multiple devices show the same result, the subscription updates normally but connection attempts are rejected, or the provider confirms an outage. An unstable exit address can also cause repeated authentication challenges or inconsistent access while ordinary websites continue to work.

Before changing provider, retain a short test record: date and time, client and core versions, operating mode, DNS mode, selected node region, matched policy, and the exact error shown by the browser. Do not include account credentials or private subscription URLs in support messages. This record prevents the same local mistake from being reproduced with a new profile.

A new provider is unlikely to fix a local port conflict, a disabled system proxy, a TUN permission failure, a browser extension, or a rule that sends traffic directly. It may provide a more stable node, but the configuration still needs to be validated after import. Recheck the active mode, proxy group, DNS path, and effective rules rather than assuming that a newly downloaded profile is correct for every client.