Clash Certificate Errors: Check System Time, HTTPS Interception, and TUN

Keep the error details, then check time, nodes, and TUN

Don't click “Proceed,” and don't install a root certificate sent to you as a quick fix. An HTTPS certificate error means your browser can't verify the identity of the server it's connecting to—not that the proxy is slow. Normal Clash proxy forwarding doesn't require disabling certificate checks, and mihomo's TUN mode doesn't decrypt HTTPS.

If you're opening email, making a payment, or accessing an admin console, stop before entering your password. Note the error code, domain, certificate issuer, and time, then compare results. The ports and domains in this guide are examples for troubleshooting, not default client settings or results tested by this site.

Check the system date, time zone, and certificate validity period to rule out an incorrect local clock.
Confirm the result with the proxy fully exited, then compare two nodes.
Check the certificate's domain and issuer for signs of a captive portal or HTTPS inspection.
Change only TUN, then check DNS, routing, and security software.
Verify your findings from the command line and roll back settings based on the evidence.

Identify the error code: a certificate error isn't the same as a TLS handshake failure

Chromium-based browsers commonly use error codes with the NET::ERR_CERT_ prefix. Firefox uses different wording and codes, but the checks are the same: time, certificate chain, hostname, and trust source. Copy the full code; don't just note “secure connection failed.”

Example error	What it usually means	Check first
`NET::ERR_CERT_DATE_INVALID`	The local clock says the certificate is not yet valid or has expired	System time and certificate validity dates
`NET::ERR_CERT_AUTHORITY_INVALID`	The certificate chain doesn't lead to a trusted root	Issuer, chain completeness, and HTTPS inspection
`NET::ERR_CERT_COMMON_NAME_INVALID`	The certificate doesn't match the current hostname	Certificate SAN, captive portal redirects, DNS, and hosts
`NET::ERR_CERT_REVOKED`	The certificate is considered revoked	Certificate details, website, or security product status
`ERR_SSL_PROTOCOL_ERROR`	A TLS negotiation problem; a valid certificate may never have been received	Proxy port, protocol, network equipment, and server

The scope matters too. If only one domain fails, suspect that site or a rule targeting it. If several unrelated HTTPS sites fail at once, check your local clock, trust store, and shared network equipment first. Don't assume the Clash core is broken just because the error appeared after you launched Clash.

Step 1: Check the system time and certificate validity

Sync the clock automatically, then retry the same URL

On Windows 11, open Settings → Time & language → Date & time. Check that “Set time automatically” is enabled, then select “Sync now.” On macOS, open System Settings → General → Date & Time and check the automatic date and time setting. If your organization manages the device and prevents changes, contact your administrator.

Check the year, month, and day first. Resuming from sleep or a failing motherboard battery can cause the clock to jump back.
Then check the time zone. A correct-looking local time doesn't guarantee the UTC time is right, so don't rely on a quick glance at the clock.
Open the certificate viewer in your browser. Note the “Valid from” and “Expires” dates and compare them with the system time.

For example, if a certificate expired before today's date and only that site fails, the site operator needs to renew it. If your system date is earlier than the certificate's start date, multiple sites may fail. Don't set your clock back to accommodate an expired certificate; that can disrupt login tokens, software updates, and other connections.

On Linux, use commands to check synchronization status

timedatectl status
date -u

On systemd-based distributions, the first command shows the time, time zone, and sync status; the second displays UTC time. If time synchronization is enabled but remains out of sync, check the active time service and its network access. After correcting the clock, reopen the site before deciding whether to change proxy settings.

Step 2: Compare direct access and proxy nodes to narrow down the issue

Turning off the system proxy doesn't necessarily mean you're connecting directly: TUN may still capture traffic, or another VPN may still control the route. First note the current mode, node, and DNS settings. Then exit the client and confirm that TUN is off and the system proxy has been restored. Don't test with unfamiliar login pages.

Test setup	What to check	What the result may indicate
Client exited; other VPNs disabled	Does the same URL still show the same error code?	If it still fails, check the site, local device, or current network first
System proxy on, TUN off, node A	Matched rule, actual exit route, and certificate issuer	Establish a baseline for standard proxy forwarding
Same mode, switch to node B	Does the error go away? Does the certificate change?	If the issue follows the node, focus on its network path
Switch back to node A and enable TUN only	Does the error occur only with TUN enabled?	Investigate routing, DNS, and conflicts with security software

After switching nodes, check the client's Connections panel to confirm the new connection is actually using that node. A policy group may automatically select another member, and a rule may send the domain to DIRECT. Close and reopen the affected tab, or restart the browser if needed, to avoid comparing against a reused connection.

Step 3: Check the certificate issuer to distinguish captive portals from interception

Standard proxy forwarding doesn't replace website certificates

When a browser sends traffic over HTTP CONNECT, SOCKS, or TUN, TLS to the destination website is normally still negotiated between the browser and the site. Enabling Clash or mihomo doesn't mean every website needs a new certificate. If several unrelated sites suddenly show the same local security product or company as the issuer, check HTTPS inspection settings and device management policies.

Corporate gateways may inspect and decrypt HTTPS traffic under organizational policy. Some security software offers a similar feature. If its root certificate isn't trusted by the browser, certificate-chain errors may result. Firefox and Chromium differ in certificate trust settings, platform integration, and enterprise policies, so a site working in another browser only narrows down the cause; it doesn't prove the connection is safe.

Hostname match: Check whether the certificate's Subject Alternative Names (SAN) include the hostname you're visiting. The wildcard *.example.com doesn't cover the root domain example.com or deeper subdomains.
Unexpected issuer: If the issuer is a router, an unfamiliar organization, or a local product, verify where it came from before trusting it.
Certificate changed: A CDN may serve different certificates in different regions. A difference alone doesn't indicate interception; also check the hostname, validity dates, and trust chain.

Complete captive portal sign-in on public Wi-Fi

Hotel and airport Wi-Fi may require portal sign-in before you can connect. Prefer the network sign-in window provided by your operating system and verify the network name. If needed, visit a known plain-HTTP page to trigger the portal. Don't enter credentials on an HTTPS certificate warning page or install an unfamiliar certificate to get through the portal. Once signed in, test again. If the certificate still doesn't match, don't use that connection for sensitive activity.

If only one node consistently presents a mismatched certificate while other nodes work, stop using that node and send the provider the time, domain, and certificate details. A faulty node, unusual exit DNS, or interference along the forwarding path are all worth investigating, but one error alone can't identify who caused it.

Step 4: If errors occur only with TUN, check DNS and routing

TUN sends system traffic through a virtual network interface; it doesn't issue website certificates. If the error starts only after enabling TUN, traffic that previously bypassed the proxy may now be captured, or the DNS, routing, or security software path may have changed. Keep the same node and rule mode, turn off TUN only, and compare the result.

A fake-IP address isn't the certificate returned by a website

With common fake-IP configurations, the core may map a domain to an address in the 198.18.0.0/16 range and handle the connection using that mapping; the active configuration determines the exact range. Seeing this kind of DNS result doesn't mean the certificate was replaced. Check whether the connection reached the core responsible for the mapping and where the destination domain was ultimately routed.

Open the connection log, search for the domain, and note the matched rule, policy group, and exit route.
Check the active configuration for dns.enhanced-mode, tun.dns-hijack, and routing settings—not just the original subscription file. A GUI client may apply overrides.
Check the browser's “Secure DNS” setting. Browser DoH and system DNS may use different routes; note the original value before changing it.
Check whether the local hosts file points the domain to an outdated address. On Windows, the usual path is C:\Windows\System32\drivers\etc\hosts; on Linux and macOS, it's /etc/hosts.
Disable other VPNs or network-filtering tools one at a time to compare results. On a managed device, get your administrator's approval first; don't uninstall several components at once.

If DNS points to the wrong server, the browser may still establish a TCP connection but receive a certificate for a different domain, causing a hostname mismatch. Routing conflicts, by contrast, are more likely to cause timeouts or connection resets. Don't label every TUN issue a certificate error. Continue investigating certificates only when the error code and certificate details point to one.

Step 5: Compare curl with the browser and verify the proxy port

The examples below assume a local HTTP or mixed proxy listener at 127.0.0.1:7890. Check the client's listener settings or active configuration to confirm the actual port; 7890 isn't universal. A website using HTTPS doesn't mean the local proxy address should be https://127.0.0.1:7890.

Two requests on Windows

curl.exe -v --noproxy "*" --connect-timeout 10 --max-time 30 https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 https://example.com/

The first command bypasses curl's explicit proxy settings; the second forces the local HTTP proxy and clears the no-proxy list. To test the affected site, replace the example domain with its public homepage—don't include a login token. On macOS or Linux, you can use curl instead of curl.exe.

Test a direct connection only after exiting TUN: --noproxy "*" can't bypass TUN routing at the operating-system level.
Distinguish CONNECT from TLS: 200 Connection established only means the proxy tunnel was created; it doesn't mean the website certificate was successfully verified.
Check the error returned: curl error 60 usually indicates peer certificate verification failed; errors 7 or 28 are more likely to mean a connection failure or timeout.
Don't add an option to skip verification: The goal is to see why verification fails, not to force the request to return a page.

curl and your browser may use different TLS backends and trust sources. If their results differ, check the certificate issuer, system proxy, browser extensions, and management policies rather than assuming one result is necessarily more reliable. Detailed logs may contain destination addresses or authentication information; redact sensitive data before sharing them.

Restore settings and retest: change one thing at a time

Once you've identified a likely cause, restore other test settings and keep only the fix that's needed. For example, if correcting the clock fixes the issue, there's no need to change DNS. If only one node is affected, disable that node first. If the failure occurs only with enterprise HTTPS inspection, ask an administrator to check the certificate deployment and policy.

Retry the URL that originally failed and confirm the same certificate error is gone.
Then test two unrelated HTTPS sites to check for a system-wide trust issue.
Confirm the destination's actual exit route in the Connections panel so you don't mistake a return to direct access for a proxy fix.
Restore any security features and DNS settings temporarily disabled during testing, and verify each change stays fixed.
Keep a record of the error code, node name, core name, TUN status, and troubleshooting steps to help reproduce the issue later.

When reporting the issue, include the actual client version, core version, operating system version, and redacted logs. Don't share subscription URLs, proxy passwords, or your full private configuration. Record the client name and core name separately: similar-looking interfaces don't mean they use the same Clash or mihomo core.

For more configuration guidance, see the DNS section of the user guide and the proxy mode guide. The key checks are always the same: Is the current time correct? Who issued the certificate? Which route did this connection actually take?