HTTPS Certificate Errors Behind a Proxy: Node Issue or Local Setting?
When the browser throws NET::ERR_CERT_AUTHORITY_INVALID or "Your connection is not private," most people's first instinct is to turn the proxy off. But certificate errors can come from three completely different layers — system clock, node behavior, and leftover local certificates — and each needs a different fix. This article breaks down the diagnosis path by error type and gives clear criteria for when you should drop a node immediately.
Identify the error type first
An HTTPS certificate error isn't one single problem — the error code the browser shows is your first clue. If a cert warning suddenly appears right after you turn on the proxy, look closely at which code it actually is before deciding where to dig. That alone saves a lot of wasted effort.
The common error codes mean different things:
- NET::ERR_CERT_DATE_INVALID — the certificate's validity window check failed, which usually points to the local system clock or time zone being wrong, not the proxy node itself.
- NET::ERR_CERT_AUTHORITY_INVALID — the issuing authority isn't trusted. This is the one to worry about most, since it can mean the connection was intercepted and re-signed midway.
- NET::ERR_CERT_COMMON_NAME_INVALID — the domain on the certificate doesn't match the domain you're visiting, often caused by a broken routing rule on the node sending the request to the wrong server.
- NET::ERR_SSL_PROTOCOL_ERROR — the transport-layer handshake failed, which could be a dropped node, an incompatible protocol, or a middle device forcibly cutting the connection.
Clash operates at the transport layer to forward traffic — it doesn't decrypt or re-issue HTTPS certificates on its own. In other words, forwarding through a node under normal configuration shouldn't change a site's original certificate at all. If the issuer, validity period, or fingerprint changes, the problem is either abnormal node behavior or an extra certificate installed locally — not a normal Clash client function.
System clock drift: the most overlooked cause
Every HTTPS certificate has a validity window, and the system checks whether the current time falls inside it. If your local clock has drifted — due to clock skew, a dead CMOS battery, a dual-boot time conflict, and so on — almost every site's certificate will be flagged as "not yet valid" or "expired," even though the certificate itself is perfectly fine.
A telltale sign of this cause: the error shows up across multiple unrelated sites, regardless of whether the proxy is on — it just looks proxy-related because turning on the proxy usually means visiting more sites. The check is simple:
Check system time and time zone
Open your system's time settings, confirm "Set time automatically" or network time sync is enabled, and verify the time zone matches your actual location. VMs and dual-boot setups are especially prone to having the clock overwritten.
Verify with the proxy off
Turn off Clash temporarily and visit one trusted site to see if the certificate error still appears. If it does, the issue is unrelated to the proxy and points straight to the system clock.
Resync, then clear cache
After correcting the time, clear the browser's HSTS cache and Certificate Transparency log cache (paths differ by browser) so stale error results don't get reused.
Errors caused by clock drift have nothing to do with nodes. No node switch or client reinstall needed — just correct the system time.
Node MITM interception: a signal to drop it immediately
If the certificate is completely normal with the proxy off, but NET::ERR_CERT_AUTHORITY_INVALID appears as soon as one specific node is turned on, that usually means there's man-in-the-middle (MITM) behavior on that link — a relay node isn't simply forwarding encrypted traffic, it's intercepting the TLS connection, re-signing it with its own certificate, and then forwarding it to the real site.
That's not something normal proxy forwarding should ever do. To confirm, check the certificate details the browser shows:
- Unusual issuer — legitimate sites are usually issued by well-known CAs like Let's Encrypt, DigiCert, or GlobalSign. An unfamiliar issuer name or a self-signed flag is a strong red flag that the link is being intercepted.
- Unusually short validity period — some MITM certificates are generated on the fly and might be valid for only a few days or even hours, far shorter than the typical year-plus validity of an official site certificate.
- Only reproduces on one specific node — if the error disappears after switching to another node under the same subscription, the problem is that specific node or its relay server, not your machine or the subscription as a whole.
Once you've confirmed a node is swapping certificates, drop that node immediately and don't use it for anything involving logins, payments, or identity verification. A MITM node can decrypt and read your plaintext traffic — continuing to use it means handing sensitive data straight to whoever operates that node. It's also worth checking whether the subscription source that node came from is trustworthy, and switching subscriptions if needed.
Worth noting: this kind of interception has nothing to do with whether a node is paid or free. Free nodes from unknown sources do carry higher risk, but that doesn't mean every free node has this problem — the judgment always comes from the certificate details themselves, not the node's pricing.
Leftover packet-capture root certificates: the forgotten third cause
There's a third cause that often gets overlooked: your system may have previously had a root certificate installed for packet-capture analysis or traffic debugging (some network analysis tools require a custom CA certificate to decrypt HTTPS traffic). If that certificate was never fully removed after debugging, it stays in the system or browser's trust store indefinitely.
A leftover certificate like this doesn't cause harm on its own, but it can lead to two typical issues:
- If the private key tied to that certificate was ever improperly stored or leaked, there's a theoretical abuse risk, and the browser may flag connections using that certificate chain as a security precaution.
- Some system-level debugging tools fail to clean up their proxy settings and certificate trust state properly when they exit unexpectedly. When you later enable a Clash node, the two trust mechanisms conflict, producing a certificate chain validation error.
To check, look through your system's and browser's certificate manager for anything issued by an unfamiliar CA whose install date lines up with a past debugging session:
- Windows: run
certmgr.mscand check the "Trusted Root Certification Authorities" list for unfamiliar names or suspicious install dates. - macOS: open Keychain Access, check certificate trust settings under "System" or "login," and look for non-default certificates marked "Always Trust."
- Browser-managed certificates: Chrome, Edge, and other browsers have their own certificate manager, kept separate from the system-level list — check both.
Once you've confirmed a debugging certificate is no longer needed, delete it outright rather than just marking it "untrusted" — on some systems, a certificate that's still present but flagged untrusted can still cause ambiguous errors during certain validation steps.
Diagnosis order and cutoff point
These three causes carry very different costs and risk levels to check, so it's worth following this order rather than jumping straight to blaming and swapping nodes without fixing the actual root cause.
Check the system clock first
Lowest cost — confirm or rule this out in under a minute, no extra tools needed.
Reproduce once with the proxy off
This confirms whether the error is tied to the proxy toggle state — the key line that separates "local environment issue" from "link issue."
Switch nodes to cross-check
If the error only shows up with the proxy on, switch between different nodes under the same subscription to see if it follows one specific node instead of affecting all of them.
Check the certificate details and local cert list
If the issue follows a specific node, check that site's certificate issuer and validity period for anything unusual. If all nodes are affected, check your machine for leftover debugging certificates instead.
A quick note on TUN mode: enabling TUN mode changes how traffic is taken over at the system level, and some security software or system firewalls may trigger extra certificate validation policies as a result — that's a system compatibility issue, unrelated to whether a node is safe. If a certificate error only appears with TUN mode on but not in regular system-proxy mode, try disabling TUN mode temporarily to narrow the problem down before deciding whether to adjust the client's network adapter settings.
The core standard for deciding whether to drop a node right away is simple: the error disappears with the proxy off, only reproduces on one specific node, and the certificate issuer or validity period is clearly abnormal — only when all three are true is that a strong signal to drop the node. A wrong system clock or a leftover debugging certificate alone doesn't mean the node itself has a security problem.
One last habit worth keeping: after switching subscriptions or adding a node from an unfamiliar source, test the certificate on a non-sensitive site first before doing anything involving accounts or payments. That keeps the risk contained to a minimum.