Which to choose: TUN mode or system proxy? A comparison of how Clash handles network traffic

Start by defining what “timeout” actually means

A ChatGPT timeout in Clash does not always mean that the remote node is slow. The failure may happen before a node is selected, while the core is resolving a domain, during the TLS handshake, or after the connection has already reached the service. The visible symptom can look identical in a browser: the page keeps loading, the application reports a network error, or a conversation fails after several seconds.

First determine whether the problem affects only ChatGPT or every proxied website. Open a simple HTTPS page, a service that you normally access through the same policy group, and ChatGPT in separate tabs. If all proxied sites time out, investigate the active node, local port, system proxy, or TUN capture first. If ordinary websites work but ChatGPT fails, focus on routing rules, DNS behavior, the selected exit region, and persistent connections.

Verify the active node and policy group

Clash sends traffic according to the final matched rule and the policy group referenced by that rule. A group named PROXY, ChatGPT, or GLOBAL may point to a manually selected node, a url-test group, a fallback group, or another nested selector. The name alone does not tell you which server is being used.

Open the client’s “Proxies” or “Dashboard” page and identify the exact chain: the ChatGPT-related rule, the selected policy group, and the final node. In many clients, clicking the group reveals the current member. If the group uses url-test, remember that its latency result is only a small health-check measurement. A node with low probe latency can still have unstable TLS connections, poor international routing, or a remote service that rejects the exit address.

Test a different node without changing rules

Choose two or three nodes from different regions and test them one at a time through the same policy group. Avoid changing the rule set during this comparison. A useful sequence is the current node, a node in the same region, and a node in a different region. Wait for the previous request to finish or fail before starting the next test, then record whether the page loads, whether a message can be sent, and how long the response takes.

• If one node works immediately and another repeatedly times out, the node or its upstream route is the primary suspect.
• If every node in one region fails but another region works, check the exit region, provider routing, and service availability from that region.
• If all nodes fail only inside one policy group, inspect the group’s members, filters, and fallback behavior.
• If a node passes a latency test but ChatGPT still fails, use a real HTTPS request rather than relying only on the displayed latency.

Do not assume that increasing a timeout value will repair a dead route. A larger timeout can make the interface wait longer, but it cannot fix a rejected connection, an unreachable DNS server, or a node that has stopped forwarding traffic. A stable node with a slightly higher latency is often preferable to a fast node that loses connections during a response.

proxy-groups:
  - name: ChatGPT
    type: select
    proxies:
      - Node-A
      - Node-B
      - Node-C
      - DIRECT

The example above creates a manual test group. The exact node names must match the proxies defined in the same configuration. Do not add DIRECT as a permanent solution if the destination is unavailable from the local network; it is useful as a diagnostic comparison because it shows whether the failure is caused by the proxy path or by direct connectivity.

Check routing rules and DNS resolution

Even a healthy node cannot help if ChatGPT traffic is matched by DIRECT, REJECT, an unintended regional group, or a policy group whose selected node is unavailable. The domain list involved in a web service may include more than the main website hostname. The page, authentication flow, API requests, static resources, and streaming or persistent connections can use different hostnames.

Open the client’s “Connections” page while loading ChatGPT and look at the destination, matched rule, and outbound policy. In a Mihomo-based client, the connection entry normally shows whether the request matched a domain rule, a rule provider, an IP rule, or the final rule. A useful diagnostic record contains the destination hostname, the matched rule, the selected group, and the final node.

DNS can fail in two different places. The client may resolve a destination locally before opening the proxy connection, or it may send a domain-based request through the proxy and let the remote side resolve it. TUN mode often adds another layer because Mihomo may use fake-IP mapping, DNS hijacking, or a virtual interface to intercept queries. A stale mapping, unavailable DNS upstream, or conflicting system resolver can therefore appear as a ChatGPT timeout.

Use a simple DNS comparison

Temporarily compare the current configuration with a simpler DNS setup. Make a backup before editing YAML, and use DNS servers that are reachable in your network. The following is only an example structure; supported fields and behavior depend on the Mihomo version and the client’s configuration template.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://1.0.0.1/dns-query

If the problem disappears after restarting the core and clearing the relevant DNS state, the original issue may be related to the resolver or fake-IP handling. If nothing changes, restore the previous DNS configuration and continue with node and mode testing. Do not keep changing public DNS addresses randomly; the important comparison is whether the DNS request completes consistently and whether the result is usable by the selected traffic mode.

Run a controlled request through the local proxy port

This is the hands-on step that separates a browser problem from a Clash path problem. First find the local mixed or HTTP proxy port in the client’s “Settings” → “Network” or “Clash Settings” page. Common examples are 127.0.0.1:7890 for a mixed port or 127.0.0.1:7891 for a SOCKS port, but your configuration may use different values.

1. Open the Clash client and confirm that the core is running and the intended configuration is active.
2. Select one known working node manually in the relevant policy group.
3. Confirm the local proxy port and check that no other process is using it.
4. Clear or pause unrelated downloads and synchronization programs.
5. Run a small HTTPS request through the local port.
6. Watch the Clash connection log and record the matched rule, node, and final error.
7. Repeat the same request with a second node, then compare the results.

For an HTTP or mixed port, a command-line test can look like this:

curl -I --connect-timeout 15 --max-time 30 \
  -x http://127.0.0.1:7890 \
  https://chatgpt.com/

For a SOCKS5 port, use the corresponding option:

curl -I --connect-timeout 15 --max-time 30 \
  --socks5-hostname 127.0.0.1:7891 \
  https://chatgpt.com/

--socks5-hostname asks the SOCKS proxy to resolve the hostname rather than resolving it locally first. This makes the comparison useful when local DNS is suspected. A successful HTTP status does not prove that every ChatGPT function will work, but it confirms that at least one HTTPS request can pass through the chosen local entry, rule path, node, and destination.

Compare system proxy with TUN mode

System proxy and TUN mode capture traffic at different layers. With system proxy enabled, an application must read the operating system’s HTTP, HTTPS, or SOCKS settings and connect to the local Clash port. With TUN enabled, Mihomo creates a virtual network interface and attempts to capture IP traffic more broadly, including applications that ignore system proxy settings.

This difference is important when ChatGPT is used in a browser, desktop application, or embedded web view. A browser may work through system proxy while a desktop client bypasses it. The opposite can also happen: the browser follows an old system proxy setting, while the desktop application is correctly captured by TUN.

Start by disabling TUN and enabling system proxy, then test ChatGPT in a browser that is known to use the operating system proxy. If this works, the node and basic rule path are probably usable, and the TUN configuration deserves attention. Next, enable TUN while keeping the same node and rules. A new timeout only after TUN is enabled suggests a local interception or DNS problem rather than a remote node problem.

Check TUN permissions and route conflicts

TUN normally requires elevated permission or a client service component that can create and manage the virtual interface. Confirm that the interface reports “running” rather than merely “enabled.” Check the core log for messages containing terms such as permission denied, interface, route, DNS hijack, or address already in use.

• Temporarily disconnect another VPN, corporate tunnel, virtualization bridge, or traffic-filtering application.
• Check whether the operating system has installed a route that sends the local proxy or DNS traffic back into the TUN interface.
• Confirm that the TUN stack is using the intended DNS mode and that fake-IP exclusions are not matching the destination incorrectly.
• Restart the Clash core after changing TUN settings so stale interfaces and routes are removed.
• On systems with a firewall, allow the client service to create the interface and receive local traffic.

Do not use TUN as a universal fix for a broken system-proxy setup. TUN expands the capture scope and can introduce route loops or conflicts. Once ChatGPT works reliably through the simplest path, add TUN only if a specific application needs full-device capture.

Read the runtime log and apply the matching fix

Set the core log level to debug only while reproducing the problem, then restore info for normal use. In most clients, the path is similar to “Settings” → “Clash Settings” → “Log Level,” although wording varies. Clear the log, load one ChatGPT page, send one short message, and preserve the entries from the DNS query through the final failure.

log-level: debug

The wording differs between Mihomo versions and desktop wrappers, but the sequence is more useful than a single error line. Look for a DNS failure first, then rule matching, policy selection, node dialing, TLS negotiation, and connection closure.

Apply the smallest fix that matches the evidence. Replace a failed node rather than rewriting the whole configuration. Correct a policy rule rather than enabling every mode. Simplify DNS only long enough to confirm the resolver as the cause. If a subscription repeatedly restores a bad rule or outdated node, update the subscription source or edit the local override instead of making temporary manual changes after every restart.

Finally, restore the log level to info, remove temporary test groups, and keep the working node or policy selection documented. A proper verification includes loading the page, signing in if required, sending a short message, receiving the response, and repeating the test after a fresh browser reload. If only one node works, keep monitoring it but treat that result as a node-quality finding, not proof that the entire configuration is healthy.