ChatGPT Not Working With Clash? Fix Timeouts and Access

Identify whether the problem is ChatGPT, Clash, or the network

When ChatGPT does not open while Clash is running, the visible symptom is often misleading. A page may remain blank, the login screen may loop, a request may time out, or the chat interface may load while messages fail to send. These symptoms do not all point to the same cause. The first task is to determine whether the failure happens before the request reaches Clash, inside the proxy route, or after the remote service receives the connection.

Start by disabling the system proxy temporarily and opening another ordinary HTTPS website. Then enable Clash again, keep the same browser window, and compare the result. If many unrelated websites fail with Clash enabled, inspect the local listener, active Profile, selected proxy group, and node availability first. If ordinary websites work but ChatGPT alone fails, focus on domain rules, DNS resolution, TLS interception, WebSocket support, and the route selected for OpenAI-related domains.

Check Clash logs before editing YAML

Open the client’s log panel and reload the ChatGPT page. In Clash Verge Rev, Clash Verge, and other mihomo-based clients, the exact menu name varies, but the log level is usually available under “Settings” or “Logs”. Temporarily use log-level: info or the equivalent normal logging level. Debug logging can provide more detail, but it may expose request destinations and create a large amount of data.

Look for the requested hostname, the selected proxy group, connection errors, and timeout messages. A request that never appears in the Clash log may be bypassing the client, blocked by the browser before connection, or going through a different network stack. A request that appears with DIRECT indicates that the rule decision did not send it through the proxy group you expected.

Verify the active Profile, proxy group, and node

ChatGPT access depends on the complete route, not merely on whether a subscription was imported successfully. The active Profile must contain valid proxy nodes, the relevant proxy group must have a usable selection, and the browser or operating system must actually send traffic to Clash. A green client icon alone does not prove that the current ChatGPT request is using a working remote route.

1. Open “Profiles” or “Subscriptions” and confirm which Profile is currently active.
2. Run one manual update, then wait for the client to finish parsing the returned configuration.
3. Open “Proxies” and identify the group used by the final matching rule.
4. Select one known working node manually instead of relying on an automatic group during the first test.
5. Enable “Settings” → “System Proxy” and confirm that the browser uses the client’s local address and port.
6. Open a new private browsing window and test ChatGPT without reusing a broken page session.

Automatic groups such as url-test may choose a node with a fast response to their test URL while that node has poor connectivity to ChatGPT. A latency result is not a complete application test. The test URL may be geographically close, cached, or routed through a different service. For troubleshooting, a manual select group is easier to reason about because you know exactly which node is being used.

Confirm the local proxy endpoint

A common mihomo configuration uses mixed-port: 7890, but your client may use 7897, 7899, or another custom value. The operating system proxy must point to the same local address and port. If Clash listens on 127.0.0.1:7890 while Windows or macOS is configured for 127.0.0.1:7897, the browser will not reach the running proxy even though the client interface looks normal.

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

Do not use external-controller, commonly configured as 127.0.0.1:9090, as the browser proxy port. The controller port is for management requests from the client interface. It is not a normal HTTP or SOCKS proxy listener.

Repair domain rules and DNS decisions

When ordinary sites work but ChatGPT does not, an incorrect rule is one of the most practical explanations. A configuration may send the main website through a proxy while sending authentication, API, static assets, or streaming endpoints directly. The browser then receives only part of the application, producing a blank page, login loop, or message timeout.

Inspect the rules in order from top to bottom. Clash uses the first matching rule, so a broad rule placed above a more specific domain rule can override your intended route. Search the active configuration for entries involving OpenAI or ChatGPT domains, GEOIP, DOMAIN-SUFFIX, DOMAIN-KEYWORD, RULE-SET, and MATCH. The final MATCH rule is especially important because it handles every request not matched earlier.

For a controlled test, temporarily set the final policy to the same proxy group used by your manually selected node. This does not permanently solve every routing design, but it answers an important question: can the selected route handle the application when broad rule classification is removed? After testing, restore the intended policy and create narrower rules rather than leaving all traffic on one route without understanding the consequences.

mode: rule

proxy-groups:
  - name: ChatGPT route
    type: select
    proxies:
      - Stable node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,openai.com,ChatGPT route
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT route
  - MATCH,DIRECT

The exact domain list depends on the service version, browser flow, and configuration provider. Do not blindly copy a large list from an unknown source. Authentication and application assets may be hosted on related domains, and a stale rule-set can be incomplete or send part of the session through DIRECT. Use the Clash connection panel or browser developer tools to discover the actual hostnames involved in your session, then verify which policy matched each request.

Test DNS resolution and fake-IP behavior

DNS problems can look like node failures. If the operating system resolves a hostname to an unreachable address, or if the client’s fake-IP mapping becomes stale, ChatGPT may fail before a stable proxy connection is established. This is particularly common after switching between TUN mode, system proxy mode, and direct access without restarting the browser or flushing stale sessions.

Check whether DNS is enabled in the active Profile and whether the DNS mode matches the routing design. A configuration using fake IP should have consistent fake-IP filtering and a client that supports the selected behavior. A configuration using redirection or TUN routing also needs a DNS strategy that prevents local DNS queries from escaping when the intention is to resolve through the proxy.

nslookup chatgpt.com
nslookup openai.com

This command only shows how the operating system resolver responds; it does not prove that the mihomo DNS module used the same path. Compare the result with the client’s DNS or connection logs. If direct DNS works but proxied DNS fails, or the reverse, change one DNS option at a time and repeat the same test. Avoid adding several public resolvers randomly, because inconsistent answers can make the diagnosis less reliable.

Perform a controlled fix in Clash

The following procedure is designed to reduce variables. It applies conceptually to Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, and other mihomo clients, although menu labels and TUN implementation details differ between platforms.

Step-by-step test sequence

1. Update the Profile. In “Profiles” or “Subscriptions”, run a manual update and confirm that the result is successful. If the update returns HTML, a login page, a timeout, or an expired subscription message, fix that source before testing ChatGPT.
2. Choose Rule mode. Use “Rule” for the initial test so that the connection panel can show which policy handled each hostname. Do not begin with a complex script or several layered rule-sets.
3. Select one stable node. In “Proxies”, choose a node manually. Avoid an auto-switching group until the page and message submission both work.
4. Enable the correct traffic path. For desktop browsers, enable “System Proxy”. For applications that ignore system settings, test TUN mode separately and avoid enabling both modes blindly if the client warns about conflicts.
5. Open a clean browser session. Use a private window, or clear site data for the affected service if the current cookies or cached JavaScript are corrupted. Do not repeatedly refresh a half-loaded login page.
6. Inspect the connection panel. Reload the page and identify whether the relevant hostnames show the expected proxy group rather than DIRECT or a rejected rule.
7. Test both page loading and message streaming. A successful page load proves only that short HTTPS requests work. Send a short message and observe whether the response begins and continues without a timeout.

If the page works after selecting a node manually but fails again when the automatic group is restored, the group’s health-check URL, interval, or node pool is not a reliable measure for this application. Keep a stable group for the affected domains or remove unstable nodes from that group. If the page still fails with every node, move to the DNS, browser, provider, or service-side checks instead of repeatedly changing nodes.

Choose between System Proxy and TUN mode

System Proxy is normally the shortest path for a browser test. It configures HTTP and HTTPS proxy settings that supported applications understand. TUN mode creates a virtual network interface and can capture applications that do not read operating system proxy settings, but it introduces additional routing and DNS variables. On Windows, macOS, Linux, and Android, the required permissions and implementation can differ.

Use System Proxy first when the target is a regular browser. If the browser succeeds but a desktop ChatGPT application does not, test TUN mode with the system proxy state documented. If TUN mode is enabled, check that the virtual interface is running, the client has the required permission, and another VPN or network filter is not installing a competing route. A loopback listener such as 127.0.0.1:7890 and a TUN interface are different traffic paths; fixing one does not automatically fix the other.

Separate local configuration errors from provider outages

A node can pass a simple TCP latency test and still fail during a real ChatGPT session. The application may require stable TLS connections, repeated API requests, server-sent streaming responses, and authentication cookies that remain consistent across requests. A route that frequently changes exit IPs or drops long-lived connections can produce an intermittent timeout even when ordinary pages open quickly.

Run a small comparison matrix and record the result. Use the same browser, the same test hostname, and one change at a time. For example, compare the current node with a second node from the same Profile, then compare the same node with another network. If all nodes fail only on one network, local DNS, firewall rules, captive portal behavior, or upstream filtering may be involved. If all users of the same provider fail at the same time, the provider route or service availability is more likely than a local YAML mistake.

Avoid common misdiagnoses

Do not assume that every timeout is caused by a blocked domain. A timeout can result from an overloaded node, a proxy group switching during a request, a local firewall rejecting the client, a wrong system proxy port, or DNS returning an unusable address. Likewise, changing the browser user agent, installing several proxy extensions, or repeatedly deleting all configuration files can hide the original evidence without fixing the route.

Do not expose your subscription URL when asking for help. Many subscription addresses contain account tokens. Remove them from screenshots and logs, and also redact node usernames, passwords, private server addresses, and external controller secrets. Share only the client type, operating system, error message, relevant rule behavior, and sanitized log lines.

Keep the working configuration stable

Once ChatGPT loads and message streaming works, save the working conditions before optimizing anything. Record the client version, mihomo core version if displayed, active Profile name, proxy group, selected node region, proxy mode, DNS mode, and local port. This small record turns a future timeout into a comparison exercise instead of a complete reconfiguration.

Keep a dedicated, clearly named proxy group for applications that require a stable route. If the provider supplies rule-set updates, update them only after preserving the previous Profile or exporting a backup. A rule update can change the order of matches, replace a policy name, or introduce a new DNS behavior. When a previously working setup breaks immediately after an update, roll back or switch to the prior Profile to confirm whether the update caused the change.

• Use a manual node selection while verifying a new Profile.
• Use url-test or fallback only after confirming that their test behavior matches your needs.
• Keep the final MATCH rule intentional; do not leave it to an unexplained default.
• Check the connection log whenever a page loads but streaming requests fail.
• Restart the browser after changing TUN, DNS, or system proxy settings.
• Remove duplicate proxy extensions that may override Clash’s system settings.
• Keep subscription URLs private and maintain a known-good local backup.

The most reliable troubleshooting order is therefore: verify the local listener, confirm the active Profile, pin one working node, check the rule match, validate DNS, test System Proxy before TUN, and then compare another node or network. This sequence separates a local Clash configuration problem from an unstable provider route without relying on guesswork.