When ChatGPT loads slowly, stops at a blank page, or reports a network timeout while Clash is enabled, the problem is not always the proxy node itself. A browser request may reach the local Clash port but be sent to the wrong policy group. DNS may return an unusable address, an IPv6 route may bypass the working IPv4 path, or a TUN interface may capture traffic differently from the system proxy. ChatGPT also uses more than one hostname for the web application, authentication, static resources, API requests, and real-time features, so allowing one domain is not always enough.

The most efficient troubleshooting method is to separate the request into layers: browser and application behavior, Clash entry mode, rule matching, DNS resolution, node connectivity, and TUN or system routing. Change one layer at a time and record the result. If ChatGPT works when the proxy is disabled but fails when Clash is enabled, that comparison is useful evidence, but it does not prove that every Clash setting is wrong. It only shows that the network path changes when Clash takes control.

Fix ChatGPT Timeouts in Clash: Troubleshooting and Access Tips

Identify whether the timeout is local, rule-related, or upstream

Start by defining what “timeout” means in your case. A page that never begins loading usually indicates a connection, DNS, or routing problem. A page that opens but remains stuck on “Loading” may have reached the main website while a secondary API, authentication endpoint, or streaming connection failed. An error such as “network error” after login can also be caused by a blocked resource or a policy group that sends only part of the required traffic through the proxy.

Use the same browser, profile, and account while comparing these conditions:

  • Clash disabled and the operating system connected directly.
  • Clash enabled with System Proxy enabled and a known working policy group selected.
  • Clash enabled with TUN disabled, if TUN is normally active.
  • Another browser or a private window with extensions temporarily disabled.
  • A second node in the same region and a node in a different region.

If ChatGPT fails only in one browser, inspect extensions, secure DNS, cached service workers, and browser proxy settings before changing the Clash configuration. If every browser fails but another application can use the same proxy, inspect the domain rules and DNS path. If all applications fail through the same node, the node may be overloaded, rate-limited, unable to reach the destination, or affected by upstream filtering.

Also verify whether the failure affects only ChatGPT. Open a few ordinary HTTPS sites and a site hosted in the same general region as your selected node. A proxy that cannot establish any HTTPS connection has a broad node or transport problem. A proxy that opens ordinary sites but fails on ChatGPT points more strongly to hostname coverage, DNS behavior, TLS inspection, routing, or destination-specific reachability.

Read the Clash log instead of relying only on the browser message

Open the client’s connection or log panel and reproduce the failure with a fresh browser request. Look for the requested hostname, the matched rule, the selected policy, and the final connection status. A useful entry should tell you whether the request was handled by a proxy group, sent DIRECT, rejected, or failed during DNS resolution. The browser may display the same timeout for several different underlying errors, while the Clash log can distinguish them.

Pay attention to repeated retries. A hostname that appears repeatedly with connection resets may be reaching the node but failing during the outbound handshake. A hostname with no corresponding Clash entry may be bypassing the configured proxy path, using a browser-owned secure DNS channel, or being served from cache. A request that is immediately marked REJECT is a rule problem rather than a slow node.

Check proxy mode, rule matching, and required hostnames

For a first test, use Rule mode rather than Global mode if you want to verify routing logic. Rule mode shows whether the configuration correctly classifies each hostname. Global mode sends eligible traffic through one selected policy and can temporarily confirm that a node works, but it hides whether a specific rule is incomplete. Direct mode is useful only as a comparison because it intentionally bypasses the proxy for traffic that reaches the Clash port.

Confirm that System Proxy is actually enabled when you expect the browser to use Clash. On desktop systems, the client may show an enabled switch while another application, VPN, security product, or manual operating system setting has replaced the proxy address. Check the effective HTTP and HTTPS proxy values and confirm that they point to the local Clash listener. Common local addresses include 127.0.0.1 or localhost, but the port depends on the client configuration.

ChatGPT traffic can involve multiple hostnames. The exact set may change over time, so avoid copying an old, unverified list into a permanent configuration. Instead, watch the Clash connection panel while opening the page, signing in, sending a message, and receiving a response. Group the observed hostnames by behavior and ensure that the relevant domains are not accidentally sent DIRECT or REJECT.

  • The main web application hostname must reach a policy that can connect reliably.
  • Authentication and account-related hostnames must follow a compatible route, or login may loop or fail.
  • Static resources and API endpoints must not be caught by a broad direct rule.
  • Streaming or event connections may require a stable long-lived connection and should not be forced through an unsuitable fallback.
  • Third-party telemetry or optional resources are not always required for basic access, so do not treat every failed request as the primary cause.

Rule order matters. Clash generally evaluates rules from top to bottom and uses the first matching rule. A broad DOMAIN-SUFFIX, GEOSITE, or rule-provider entry placed above a more specific domain rule can send traffic to the wrong policy. Check the actual matched rule in the client rather than assuming that the last rule in the file takes priority. Also verify that the policy group is not set to a dead node, an unavailable fallback, or an automatic group whose health check is outdated.

Test the node and DNS path separately

A node can appear online in the client while still being unsuitable for ChatGPT. A basic health check may test only TCP reachability or a simple URL. It may not measure TLS negotiation, sustained streaming, latency under load, or access to the particular destination. Select a node manually and compare connection behavior instead of relying only on an automatic group label such as “URLTest” or “Auto.”

Run a controlled node comparison. Keep the browser, rules, mode, and DNS settings unchanged. Test three nodes when available: the current node, another node from the same region, and a node from a different region. Record time to open the page, time to complete login, whether a message can be sent, and whether the response stream stops. A node that opens the front page but consistently fails during message generation may have unstable long connections or insufficient upstream capacity.

Next, inspect DNS. DNS failure can appear as a proxy timeout because Clash cannot obtain a usable address before the outbound connection begins. Check whether the client logs show resolution errors, repeated fallback attempts, or an address family that cannot be reached. If the configuration uses fake-IP, verify that the fake-IP range is not colliding with a local network, VPN route, container network, or corporate subnet. If fake-IP is disabled, confirm that the resolver used by the operating system is not returning an address that is blocked or unreachable from the selected node.

Do not change every DNS option at once. Test the current configuration first, then compare one alternative resolver or strategy. Pay attention to the distinction between the resolver used to find the proxy server and the resolver used for proxied destinations. In mihomo-based configurations, remote DNS, nameserver policies, fallback groups, fake-IP filters, and IPv6 preferences can all affect the final path. A resolver may be fast but still return an address that performs poorly from the node’s region.

mode: rule
log-level: info
mixed-port: 7890
ipv6: false

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

The example is a diagnostic starting point, not a universal configuration. Field support depends on the running kernel and client. If a configuration parser reports an unknown field, check the kernel version and remove unsupported options rather than adding more changes. Disabling IPv6 for a test can help identify an unreachable IPv6 path, but it is not automatically the best permanent choice for every network.

Follow a controlled five-step repair procedure

The following procedure is designed to isolate the failure with the fewest variables. Complete each step, reproduce the same ChatGPT action, and keep notes before proceeding.

  1. Confirm the local listener. Open Clash’s port settings and verify that the client is running, the selected configuration is active, and the browser is using the same HTTP or mixed port. If another VPN or proxy service owns that port, stop the competing service or assign separate ports.
  2. Choose one known working node. Temporarily select a node that successfully opens ordinary HTTPS sites. Avoid changing the node and rule mode at the same time. If no node works, update the subscription through the client and inspect the update log for expired credentials or malformed content.
  3. Test Rule mode, then Global mode. In Rule mode, watch the matched policy for the main page, login, API, and streaming requests. If Rule mode fails but Global mode works, repair the rules or policy group. If both fail, continue to the node and DNS checks.
  4. Test DNS without rewriting the whole configuration. Clear the browser DNS cache, restart the client if necessary, and repeat the request. Compare the current DNS strategy with one compatible alternative. Look for resolution errors and address-family differences in the log.
  5. Test TUN only after the proxy path is understood. Disable TUN and use System Proxy for a browser test. If the browser works in System Proxy but fails in TUN, inspect virtual-interface permissions, route priority, DNS hijacking, and conflicts with other VPN software. If both modes fail, TUN is unlikely to be the original cause.

After finding the first working combination, restore settings one by one. For example, begin with one node, Rule mode, System Proxy, and the tested DNS strategy. Then re-enable the policy group, IPv6, TUN, or automatic node selection separately. This sequence identifies the setting that reintroduces the timeout and leaves you with a reproducible configuration rather than a temporary collection of guesses.

Understand TUN, system proxy, and application bypasses

System Proxy and TUN are traffic entry methods, not replacement rule modes. System Proxy works when an application reads the operating system’s HTTP, HTTPS, or SOCKS settings and sends requests to the local Clash port. It is usually the simplest diagnostic path for a browser. It does not automatically capture programs that ignore system settings, use their own network stack, or run inside a separate virtual machine or container.

TUN creates a virtual layer-3 interface and uses routes to send IP packets into the Clash or mihomo core. It can cover applications that do not understand system proxy settings, but it requires additional permissions and introduces more variables. A desktop VPN, antivirus filter, virtual machine bridge, Docker network, or another tunnel can compete for route priority. DNS requests may also be redirected differently when TUN is active.

If ChatGPT works through System Proxy but times out through TUN, check the following points:

  • Whether the TUN interface is running with the required administrator or root permission.
  • Whether the default route and more specific routes point to the intended virtual interface.
  • Whether IPv4 and IPv6 are being handled consistently.
  • Whether DNS hijacking or fake-IP behavior is enabled and compatible with the client kernel.
  • Whether another VPN, firewall, or security tool is intercepting the same traffic.
  • Whether the browser is using a separate secure DNS or proxy setting that conflicts with TUN.

Do not enable TUN simply because it appears to provide more coverage. If the only affected application is a browser that already follows System Proxy, first stabilize the simpler path. Use TUN when you need to capture applications that bypass system proxy, and validate it with logs and route information after the browser path is known to work.

Apply a durable fix and prevent recurring timeouts

Once the cause is identified, keep the final configuration narrow and maintainable. Use a dedicated policy group for the affected destinations if your configuration supports it, but avoid a large collection of overlapping domain rules with unclear precedence. Keep a reliable manual fallback in the group so an automatic health check does not select an unusable node during a temporary measurement error.

Review subscription updates after applying a local rule override. Some clients place generated subscription content and local overrides in different sections or files. A later update may replace edited rules, change the policy-group name, or introduce a rule provider that takes priority. After each update, verify the active configuration, selected kernel, rule hit, and policy group. Do not assume that a successful subscription refresh means the resulting configuration is valid for the current kernel.

For DNS, use a strategy that matches the network rather than copying settings from another device. Keep fake-IP exclusions for local domains and services that require real addresses, and check for conflicts with private address ranges. If IPv6 is unreliable on the node or local network, disabling it as a documented troubleshooting decision may be preferable to leaving intermittent dual-stack failures unexplained. If IPv6 is required, test it explicitly instead of inferring support from the presence of an IPv6 option.

Browser maintenance can also prevent misleading results. Clear stale site data only after recording the current behavior, then retry in a private window. Temporarily disable extensions that alter requests, inject scripts, manage cookies, or provide their own VPN. Avoid repeatedly logging in and out while a node is unstable; authentication systems may trigger additional checks that make an ordinary transport problem look like an account issue.

A good final verification includes a fresh browser session, successful page loading, login completion, one message submission, a complete streamed response, and a second request after several minutes. Watch the Clash log during all stages. The final test should use the intended Rule or Global mode, the intended node policy, and the intended TUN or System Proxy setting—not a special emergency configuration that will not be used later.

Continue with a clean Clash setup

Choose a client that matches your platform, verify the active mihomo or Clash-compatible kernel, and then configure the subscription, proxy mode, DNS path, and policy rules in separate steps.

Go to downloads View setup guide
Download Clash