After enabling a Clash or Clash Meta (mihomo) client, your browser may suddenly show “Your connection is not private,” “The certificate is not trusted,” or “The certificate does not match the domain.” An application may also report a failed TLS handshake. It is easy to blame the proxy node, but HTTPS validation depends on system time, the target website’s certificate, DNS resolution, the operating system trust store, upstream network devices, and the application’s own certificate policies. The proxy only changes one segment of the connection path.

Standard HTTP CONNECT, SOCKS5, and TUN forwarding do not automatically decrypt HTTPS traffic. The client typically only sends encrypted traffic through the selected exit; the target server still provides the website certificate. mihomo domain sniffing identifies the hostname associated with a connection, but it does not replace the website certificate. Troubleshooting should therefore begin by identifying the error type and then using controlled comparisons to locate the failing layer—not by repeatedly importing subscriptions or switching proxy modes at random.

First identify the type of HTTPS certificate error

When establishing an HTTPS connection, the client checks the certificate’s validity period, hostname, issuer chain, and intended use. Different errors point to different causes. Record the browser error code, affected domain, certificate issuer, and validity period; this is far more useful than saving a screenshot that only says the site will not open.

The certificate is not yet valid or has expired

First check the date, time, and time zone on the computer or phone. If the system clock is off by several months, many legitimate websites will fail at once. If only one site fails, the more likely causes are an expired site certificate, an incomplete server deployment, or an edge server that a particular exit is reaching before its certificate has been updated. If automatic time synchronization is enabled but the clock is still wrong, verify the selected time zone—not just the displayed hour.

The certificate hostname does not match

The hostname in the certificate differs from the domain in the address bar. Common examples include a certificate issued to another website, a network captive portal, or an internal gateway. Possible causes include DNS returning the wrong address, a local hosts override, transparent gateway redirection, an incorrect virtual-host configuration, or a proxy exit connecting to an unexpected server. If the certificate is issued to a router admin domain, a public Wi-Fi login domain, or an unfamiliar corporate gateway, first check whether the current network requires authentication.

The certificate issuer is not trusted or the certificate chain is incomplete

The server must provide the complete chain from the site certificate through the intermediate certificates, after which the system completes validation using a trusted root built into its trust store. An outdated root store, a site that omits an intermediate certificate, or an enterprise security gateway performing HTTPS inspection can all trigger this error. Some browsers use a separate certificate store, so the same site may work in one browser and fail in another—an important clue when diagnosing trust-store problems.

The TLS handshake failed without a clear certificate page

Command-line tools and applications may only show brief messages such as handshake failed, certificate verify failed, or unknown CA. The cause may also involve supported TLS versions, Server Name Indication, certificate pinning, an incorrect upstream proxy protocol, or a connection closed midstream. Check the Clash and application logs together to determine whether the failure occurred while connecting to the node, connecting to the destination, or validating the certificate after it was received.

Use controlled comparisons to determine whether the problem is the device, network, or proxy path

Good troubleshooting changes only one condition at a time. If you change the node, DNS, TUN settings, and browser together, you cannot tell which change affected the result. Start with a domain that fails consistently and record the current configuration name, proxy mode, policy group, and selected node.

  1. Access the same domain with the proxy disabled. Turn off the client’s system proxy and TUN interception, then confirm that traffic has genuinely returned to a direct connection. If the direct connection also fails, check the system time, website certificate, and current network first.
  2. Keep the configuration unchanged and switch only the node. If one node fails while others work, the likely causes are that exit’s DNS, upstream network, transparent inspection device, or a server returned for a particular region.
  3. Keep the node unchanged and compare system proxy with TUN. If the problem occurs only in TUN mode, check DNS hijacking, Fake-IP mappings, route conflicts, and other network-filtering software. If only the system proxy fails, check whether the application uses a separate proxy setting.
  4. Test with another browser or a command-line client. A failure in one browser may involve its certificate store, extensions, cached HSTS state, or security settings. If every application fails, the problem is more likely at the system or network layer.
  5. Switch devices while keeping the same network. If only one device fails, check its time, certificate store, and network components. If multiple devices on the same network fail, inspect the router, captive-portal authentication, and upstream gateway.
  6. Switch networks while keeping the same device. If the home network fails but mobile data works, the problem is more likely local DNS, the gateway, or the carrier path than the client configuration itself.

How to check system time, certificate chains, and intermediary proxies

Verify system time and certificate validity

First synchronize the system with a reliable time source, then fully quit and restart the browser. Open the certificate details and check “Issued to,” “Issued by,” the validity start and end times, and the certificate path. If the current date falls outside the validity period, do not assume from the page alone that the website certificate has expired; an incorrect system year produces the same result.

When a desktop operating system has gone without updates for a long time, its root certificate store may also be outdated. Use the operating system’s official update mechanism to refresh trust data rather than downloading and manually installing a root certificate from an unknown page. If the organization’s network requires an internal root certificate, ask the network administrator to verify its fingerprint, supported devices, and deployment scope before following the organization’s installation process.

Identify HTTPS inspection and intermediary proxies

Corporate gateways, parental-control tools, security software, and debugging proxies may terminate the original TLS connection and issue a temporary certificate for the target domain using a locally trusted certificate. The hostname may still be correct, but the issuer changes to an organization name or a local security product. If the corresponding root certificate is missing, expired, or installed only in the system store rather than the browser’s separate store, an untrusted-certificate error appears.

Ordinary Clash rule-based routing does not perform this kind of certificate replacement. If you see an unfamiliar issuer, check for packet-capture tools, filtering software, antivirus HTTPS scanning, corporate proxies, and upstream HTTP proxies running on the system. Do not import a root certificate offered by an error page just to remove the warning: once trusted, a root certificate can be used to issue certificates for any website.

Use commands to inspect the handshake

If the necessary tools are installed, you can inspect the response and certificate chain. Replace the domain in the commands below with the site that actually fails, and keep certificate verification enabled—do not add an option that skips verification.

curl -Iv https://example.com/
openssl s_client -connect example.com:443 -servername example.com -showcerts

curl can show the connection target, proxy tunnel result, and certificate verification reason; openssl s_client can show the certificate chain returned by the server. When using the system proxy, also confirm that the command-line tool actually reads the proxy environment variables; otherwise it may still be testing a direct connection. If the certificate issuer changes with the node, the paths from different exits to the destination differ. If the issuer stays the same but only one application fails, investigate that application’s trust store and certificate-pinning policy.

How Clash system proxy, TUN, and DNS affect certificate errors

System proxy mode

System proxy mode typically lets applications that support proxy settings connect through an HTTP or SOCKS interface. When visiting an HTTPS site, an HTTP proxy usually creates a tunnel to the destination host with CONNECT, while the TLS handshake still takes place between the application and the website. If an upstream proxy rejects, alters, or requires additional authentication for the CONNECT request, the application may report a proxy connection failure or receive a certificate page generated by a gateway.

Some applications do not read the system proxy and connect directly; others retain their own proxy settings. When “the browser works but a specific application fails,” confirm whether that application uses the system proxy, TUN, or its own networking stack. If there is no corresponding connection in the Clash log, the traffic often never entered the client at all—it is not necessarily a rule-selection error.

TUN mode

TUN mode intercepts more traffic at the network layer, making it useful for applications that do not support system proxies. It changes packet routing and DNS handling, but broader interception does not automatically decrypt TLS. If enabling TUN causes a hostname mismatch, focus on the DNS mode, other virtual adapters, route priority, and whether another VPN or filtering service is running on the device.

When multiple network components intercept traffic at the same time, packets may pass through one filter before reaching mihomo, while the return path may differ. Temporarily keep only one traffic-interception component enabled, then restore the others one by one after confirming the problem is gone. Mobile devices typically allow only one primary VpnService; when another app replaces the session, the symptom may be a loss of connectivity rather than a clear certificate error.

Fake-IP, domain sniffing, and certificate hostnames

Fake-IP mode first returns a reserved address to the application, then uses the mapping in the core to find the original domain and establish the connection. This does not make the website certificate use the Fake-IP address, because the browser still validates the certificate against the original hostname. Focus instead on expired mappings, DNS requests bypassing the client, special applications that validate certificates against an address, and inappropriate hosts overrides.

Domain sniffing can identify the hostname from information such as the TLS ClientHello to help match rules, but sniffing does not issue certificates or change system trust. If disabling sniffing makes the error disappear, check rule matches, destination restoration, and exclusions for special domains rather than installing an extra root certificate. For LAN services, private domains, and devices using self-signed certificates, set direct-connection and DNS exceptions according to the actual use case, while deploying certificates through the proper organizational or device-managed process.

Fix steps ordered by risk and effort

The sequence below starts with low-risk, easy-to-verify actions and suits most cases where HTTPS certificate errors appear after enabling a proxy. Retest the same domain after each step and record the result.

  1. Correct the date, time, and time zone. Enable automatic synchronization and restart the application showing the error. If many websites report that certificates are expired or not yet valid, make this the highest priority.
  2. Check whether the error affects only one website. For a single-site problem, inspect the site certificate’s validity period and hostname, then wait for the site administrator to fix it. Do not disable global verification to accommodate one site.
  3. Complete captive-portal authentication. With the proxy disabled, open a standard network-check page and confirm that the hotel, campus, or shopping-center network is not waiting for sign-in. Restore the proxy after authentication is complete.
  4. Switch to a known-good node. If only a particular exit fails, temporarily remove that node and report the destination domain, time, and node name to the service provider.
  5. Check Clash rule matches and logs. Confirm that the destination domain enters the expected policy group and is not sent to an unavailable upstream proxy by a rule. Handle DNS failures, connection refusals, and TLS errors in the logs as separate issues.
  6. Compare system proxy with TUN. Determine whether the problem exists in only one interception method, then inspect the corresponding proxy settings, virtual adapter, DNS, and routes instead of changing everything at once.
  7. Retest after disabling conflicting network filters. Disable only one VPN, packet-capture proxy, or HTTPS-filtering feature at a time, and restore it afterward if needed.
  8. Update the operating system and browser. Keep the root certificate store, TLS components, and browser trust data supported and current. Older applications may not recognize newer certificate chains.
  9. Verify internal certificate deployment. On a corporate or school network using an internal CA, have the administrator provide the official installation method. Do not download a certificate temporarily from an error page.
  10. Check or rebuild the client configuration last. Adjust YAML, the subscription, or configuration files only when the logs show abnormal DNS, rule, or upstream-proxy settings. Reimporting the same problematic configuration will not change the certificate chain.

Common misconceptions and further diagnosis

Repeatedly switching between Global, Rule, and Direct modes

Switching modes only changes which policy handles the traffic; it does not repair the system time or root certificate store. Its value is comparative: if direct access works but proxy access fails, inspect the exit and proxy path; if all three modes fail, address the device or network environment first. Restore the original mode after testing to avoid confusing later results.

Blaming every TLS error on DNS

DNS can indeed send a domain to the wrong server and cause a hostname mismatch, but an “untrusted issuer” usually points to the certificate chain or HTTPS inspection. Inspect the actual certificate first, then decide whether to clear the DNS cache, change resolvers, or check Fake-IP. Changing DNS alone cannot fix an expired certificate or a missing intermediate certificate.

Installing a self-signed certificate immediately

Home routers, development environments, and internal corporate services may use self-signed certificates, but confirm the service owner and certificate source before installing one. A public website suddenly presenting a self-signed certificate is usually abnormal. If the certificate comes from an unfamiliar gateway, stop entering account credentials and check network authentication, proxy settings, and changes to the device’s root certificates.

Only one application fails

Banking, payment, streaming, and some enterprise applications may use certificate pinning and accept only a preconfigured server public key or certificate chain. Even if the system trusts a certificate issued by an intermediary proxy, the application may still reject the connection. This usually indicates TLS inspection in the traffic path or a replaced destination connection. Bypass the relevant inspection device for that application or follow the organization’s network policy instead of trying to alter the application’s verification logic.

The complete diagnosis can be reduced to four questions: Who issued the certificate? Does the error change with the device? Does it change with the network? Does it change with the node or interception mode? These answers usually narrow the cause to system time and the trust store, the destination website, the current network, a specific proxy exit, or a local traffic-interception component. The goal is to restore the correct certificate chain and connection path—not merely make the warning page disappear.