Clash Certificate Errors: Fix NET::ERR_CERT Warnings When Using a Proxy

Note the certificate error before you do anything; don’t proceed to the site

When Chrome or Edge shows “Your connection is not private,” note the full error code at the bottom of the page. NET::ERR_CERT_DATE_INVALID and NET::ERR_CERT_AUTHORITY_INVALID call for different checks—not a blanket assumption that “the node is bad.” If the address is for a payment site, email, work login, or admin console, don’t enter your password.

With standard Clash or Clash Meta (mihomo) proxy forwarding, certificates for destination websites are not reissued. Whether the browser creates an HTTP CONNECT tunnel or TUN captures the traffic, HTTPS is typically still established between the browser and the destination website. Enabling a proxy does not mean you need to install an unverified root certificate.

Record these four details

URL and error code: Record only the domain and any necessary path. Remove login tokens, query parameters, and personal information before sharing.
Scope: Is the problem limited to one site, or are multiple unrelated HTTPS sites failing?
Connection path: Note whether the system proxy or TUN is enabled, and which rule group and actual node are in use.
Certificate details: Use the error page or the browser’s certificate viewer to note the issuer, validity dates, and Subject Alternative Names (SANs). The viewer’s location may vary by browser version.

Narrow down the cause by NET::ERR_CERT code

Error code	What it usually means	Check first
`NET::ERR_CERT_DATE_INVALID`	The certificate is not yet valid or has expired, or the device clock is incorrect.	System date and time, time sync, and the certificate’s validity dates.
`NET::ERR_CERT_AUTHORITY_INVALID`	The browser cannot build a chain of trust to a trusted root certificate.	Self-signed certificates, missing intermediate certificates, HTTPS inspection software, and root certificate policies.
`NET::ERR_CERT_COMMON_NAME_INVALID`	The hostname you visited does not match a name covered by the certificate.	SANs, incorrect DNS resolution, captive portal redirects, and website server configuration.
`NET::ERR_CERT_REVOKED`	The certificate has been marked as revoked.	The website’s certificate status and local security software. Don’t weaken verification to continue.

The COMMON_NAME in an error name doesn’t mean browsers check only the certificate’s CN field. Modern browsers primarily use SANs to verify hostnames. For example, if you visit www.example.com but receive a certificate that covers only portal.example.net, hostname verification will fail.

ERR_SSL_PROTOCOL_ERROR and ERR_TUNNEL_CONNECTION_FAILED are not the same as the certificate errors above. The first can occur during TLS negotiation; the second may mean the proxy tunnel was never established. The browser may not have received the destination site’s certificate at all, so check the client’s connection details and logs first.

Date errors: correct the system clock, then check the site’s certificate validity

If many sites show NET::ERR_CERT_DATE_INVALID, check the clock in your taskbar first. A device that has been off for a long time, a failing battery, or a manually changed year can make valid certificates appear expired or not yet valid. A different displayed time zone alone won’t necessarily cause this error; what matters is whether the system clock itself is accurate.

Windows 11: Go to Settings → Time & language → Date & time, turn on Set time automatically, check your time zone, then select Sync now under Additional settings.
macOS: Go to System Settings → General → Date & Time and turn on Set time and date automatically.
Android: Search Settings for “Date & time” and turn on automatic time. Menu locations vary by manufacturer.
After correcting the clock, fully quit and reopen the browser, then revisit the same URL. If the clock drifts again after a restart, check the system time sync service or hardware clock.

If the system clock is correct and only one site fails, check that site’s certificate validity dates. If the certificate has expired, the site owner needs to renew it. Switching nodes might happen to connect you to another server, but it won’t fix the site’s certificate. Give the site owner the failing domain, time, and certificate validity dates to help them investigate.

Unexpected issuer: check for leftover MITM tools and security software

If certificates for multiple unrelated sites show the same unfamiliar issuer, check whether software is inspecting HTTPS traffic. MITM inspection intercepts traffic; debugging proxies, corporate gateways, and some security software can reissue site certificates using a locally trusted certificate. This is separate from standard Clash traffic forwarding.

Disable certificate re-signing first, then verify the certificate’s source

Quit tools previously used for packet capture, such as Fiddler, Charles, or mitmproxy, and turn off HTTPS decryption or SSL Proxying in each tool. Closing a window doesn’t always stop its background process.
Check your security software for HTTPS scanning or encrypted connection inspection. On a personal device, you can temporarily disable the feature for comparison, then restore it according to the product documentation. On a managed device, contact your administrator first.
On Windows, press Win + R, enter certmgr.msc, and check Certificates under Trusted Root Certification Authorities for the current user. For computer-level certificates, use certlm.msc.
On macOS, open Keychain Access and check certificates and trust settings in both the login and System keychains.

A root certificate being present doesn’t prove that traffic is currently being re-signed; the corresponding proxy or inspection service must also be involved. Conversely, if the re-signing service is still running but its trusted certificate has been removed, the issuer will appear untrusted. Check the proxy settings, running processes, and certificates together instead of repeatedly adding and deleting certificates in the certificate manager.

Hostname mismatch: distinguish DNS issues, captive portals, and site configuration

NET::ERR_CERT_COMMON_NAME_INVALID often means the request reached the wrong server, but this error alone doesn’t prove DNS poisoning or node hijacking. A misconfigured website CDN, a public Wi-Fi captive portal, or entering an IP address manually can cause the same error.

Check local overrides first, then trace how the hostname resolves

Make sure the domain in the address bar is spelled correctly and hasn’t been replaced with a bare IP address. Certificates usually cover domain names, not necessarily server IPs.
Check whether the hosts file contains a leftover test mapping. On Windows, the path is C:\Windows\System32\drivers\etc\hosts; on macOS and Linux, it is /etc/hosts. Make a backup before editing.
On networks such as those at airports or hotels, use the system’s network sign-in prompt to complete captive portal authentication. Never enter a portal password on a certificate error page impersonating the HTTPS site you meant to visit.
If browser Secure DNS is enabled, it may use a different resolution path from the system. In Chrome, go to Settings → Privacy and security → Security and check Use secure DNS. Note the original setting before changing it temporarily for comparison.

On Windows, use the commands below to see what the system’s default resolver returns, then clear the system cache after correcting the hosts file or system DNS. The domain shown is an example; replace it with the domain that’s actually failing.

nslookup example.com
ipconfig /flushdns

nslookup alone can’t prove which address the browser actually used. With mihomo TUN, DNS hijacking, or fake-ip enabled, queries may be intercepted; a synthetic address in the 198.18.0.0/16 range in fake-ip mode is not necessarily a problem. Check the current dns, enhanced-mode, and fake-ip-range settings along with the client’s connection details.

Don’t change DNS, switch nodes, and clear the cache all at once. Change one thing per test, close existing connections, then try again. CDNs commonly return different IPs on different networks, and a different IP alone isn’t evidence of DNS poisoning. The key check here is whether the certificate covers the requested domain.

Compare direct and proxied connections to isolate proxy path issues

If the problem occurs only when the proxy is enabled, run a controlled comparison. Use a public page that doesn’t require login, and record the results for the same domain when connecting directly and through nodes A and B. With an auto-select rule group, the active node may change, so confirm the actual outbound node in the connection details instead of noting only the rule group name.

Capture the current setup: Record the configuration, rule mode, system proxy setting, and TUN status. Pause other VPNs and debugging proxies to avoid chaining connections.
Test a direct connection: Turn off Clash system proxy and TUN. Check that no manual proxy or automatic configuration script is still set in the system, then quit the client and reopen the browser. Quitting the client alone may not clear every proxy setting.
Test the proxy: Restore the original configuration, use a fixed node to visit the same domain, and check the matched rule and outbound connection in the connection details.
Change one variable: Keep the rules and DNS settings unchanged, switch to another trusted node, then compare the certificate name, issuer, and error code.

For a command-line comparison, specify the local proxy port

This Windows example assumes the client shows 7897 as its HTTP or mixed port; use the port shown in your client. For an explicit proxy test, turn off TUN to avoid transparent traffic interception during what should be a direct comparison. On macOS and Linux, you can usually change the command name to curl.

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

The first command bypasses the explicit proxy; the second uses the local HTTP proxy. Don’t add -k or --insecure, which would bypass the certificate check being tested. -I sends a HEAD request; a 405 from some sites doesn’t indicate a certificate error. If you receive an HTTP response, TLS verification has usually succeeded for that request.

curl and your browser may use different trust stores and proxy routes, so a successful command-line test doesn’t replace a browser test. Before sharing -v output, remove sensitive information such as authorization headers, cookies, and internal addresses. Don’t paste subscription URLs into a command line or public testing website.

Use the comparison results to choose your next step

Direct connection works, but one node fails: Stop using that node and report the failing domain, time, certificate issuer, and error code. If unrelated sites repeatedly receive the same unexpected certificate, consider the possibility of redirection or interception, but verify it with other evidence.
All nodes and direct connections fail: Recheck the system clock, local HTTPS inspection, root certificates, and current network. Don’t keep replacing your subscription.
One site fails on multiple networks: The site owner may need to fix its certificate chain, renew an expired certificate, or correct its CDN configuration.
The browser fails, but the command-line test works: Check browser extensions, policies, Secure DNS, and browser-specific certificate settings. Firefox may also use different trust settings from Chromium-based browsers.

Restore settings and retest; don’t leave certificate checks bypassed

The configuration option skip-cert-verify: true is not a general fix for browser certificate errors. For proxy protocols that use TLS, this setting usually controls whether the core verifies the proxy server’s certificate; it doesn’t make the browser trust destination websites. Changing it can weaken authentication of the proxy connection without fixing a website certificate’s hostname, validity, or chain of trust.

TUN also changes how traffic is routed; it doesn’t issue certificates for websites. If the error appears only with TUN enabled, check whether traffic is routed through a different node, DNS is being intercepted, or another VPN is conflicting. Don’t immediately install a certificate on the system.

Restore any temporarily changed Secure DNS, security software inspection, and rule group settings to their verified values.
Fully restart the browser, then test the domain that originally failed and another domain that was working.
Confirm that system time sync is working, the error page no longer appears, and the rules and node in the connection details are as expected.
If you continued past a certificate warning and entered your password, change it from a trusted device and network, review your active sessions, and follow the account provider’s security steps.

Follow the same order when troubleshooting certificate errors: note the full code, check the system clock, inspect the certificate issuer and hostname, then compare direct and proxied connections. This helps separate local trust issues from website configuration and proxy path problems, without repeatedly changing settings or disabling verification and hoping for the best.