Browser Shows HTTPS Certificate Errors After Enabling a Proxy? Common Causes and Clash Troubleshooting Steps

Types of Certificate Errors and What They Mean

Browser certificate errors may look varied, but they generally fall into just a few categories: untrusted certificate (NET::ERR_CERT_AUTHORITY_INVALID), expired or not-yet-valid certificate (NET::ERR_CERT_DATE_INVALID), domain mismatch (NET::ERR_CERT_COMMON_NAME_INVALID), and generic warnings about a hijacked connection. These warnings exist because the browser is doing exactly what it's supposed to do — during the TLS handshake it verifies whether the server's certificate chain is trustworthy, whether it falls within its validity period, and whether it matches the domain being accessed. If these errors don't appear before enabling a proxy but show up frequently afterward, the issue is almost certainly with the local clock, the DNS resolution path, or the certificate trust chain on your device — not with the destination site itself.

When troubleshooting this kind of issue, first note down clearly: whether the errors appear on every site or only on some; whether they occur with every node or disappear after switching nodes; whether disabling the proxy fixes it immediately, or the problem persists even with the proxy off. These three comparisons quickly narrow the scope down to the system level, the proxy level, or local software.

Certificate Errors Caused by System Clock Drift

TLS certificate validation checks whether the current system time falls within the certificate's validity window. If a device's clock is off from the real time by more than a few minutes, certificate validation may flag the certificate as "not yet valid" or "expired," even though the certificate itself is perfectly fine. This is especially common on virtual machines, dual-boot setups, and devices waking from long periods of sleep. It has no direct connection to whether you're using a proxy, but it often only gets noticed after switching nodes or restarting the client, which makes it easy to mistake for a node-related problem.

1. Check whether the system clock syncs automatically

   On Windows, go to Settings → Time & Language and confirm "Set time automatically" is enabled. On macOS, go to System Settings → General → Date & Time and confirm automatic setting is checked.

2. Manually verify the time zone

   Even with clock sync enabled, an incorrect time zone can still throw off certificate validity checks — especially on devices that recently had their region settings changed.

3. Force a fresh time sync

   Turn off automatic sync and re-enable it, or manually trigger a sync in the system's time service, so the local clock immediately aligns with a network time server.

Node Hijacking and Man-in-the-Middle Risks

If certificate errors only appear when connected to one specific node, and switching to another node immediately resolves them, take that signal seriously. A normal proxy relay never interferes with the TLS handshake — the connection between the client and the destination site is end-to-end encrypted, and the proxy server in between only forwards already-encrypted packets. In theory it has neither the ability nor the need to view or replace the certificate. If an exit node is performing a traffic-level man-in-the-middle intervention — for example, inserting a self-signed certificate to decrypt traffic — the browser will immediately flag the certificate as untrusted, because the issuer presented doesn't appear anywhere in the system's trusted root certificate list.

This is most common with free nodes of unknown origin, suspiciously cheap offerings, or unvetted third-party shared nodes — reputable, trustworthy providers rarely have this problem. The troubleshooting steps are straightforward:

• Note the name of the node in use when the error occurs, then switch to other nodes under the same subscription to see whether it recurs.
• Check the certificate issuer shown in the error details (click the padlock icon in the browser's address bar → Certificate Information). If the issuer is an unfamiliar, self-built CA instead of the well-known certificate authority the site normally uses, this essentially confirms man-in-the-middle behavior at the node level.
• Once the problematic node is confirmed, remove it from your selected group in the client and switch to a subscription from a trustworthy source.

DNS Pollution Fallback Issues in TUN Mode

TUN mode takes over all of the system's network traffic, including DNS queries. In TUN mode, the Clash Meta (mihomo) core typically enables its own DNS resolution logic, prioritizing encrypted DNS (such as DoH/DoT) combined with a fake-ip or redir-host strategy to avoid pollution from local network DNS hijacking. But if there's a gap in the DNS configuration — for example, enhanced-mode isn't correctly enabled, or the nameserver list includes plain DNS servers that are easily polluted — the system may quietly fall back to the device's default DNS when TUN-mode resolution fails. If that default DNS sits within a polluted network environment, the resolved IP will point to the wrong server, which naturally can't present a valid certificate matching the target domain, so the browser reports a domain mismatch or untrusted certificate error.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.example.net/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://dns.google/dns-query
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

When checking the configuration, focus on three things: whether enhanced-mode is set to fake-ip (or redir-host, depending on your use case), whether every entry in nameserver uses encrypted DNS rather than plain udp:// addresses, and whether dns-hijack covers port 53 to force all DNS requests through the client's own resolution logic. Missing any one of these can cause resolution to fall back to an untrusted path under certain network conditions.

Leftover Certificates from Local Packet-Capture Tools

Another easily overlooked source is a debugging proxy or packet-capture tool previously installed on the device. To decrypt HTTPS traffic for analysis, these tools typically generate a self-signed root certificate and ask the user to manually add it to the system's trusted list, which lets the tool "legitimately" act as a man-in-the-middle. If that certificate isn't removed when the tool is uninstalled, or if it has expired but remains in the trusted list, a certificate warning can be triggered later whenever proxy traffic happens to pass through leftover configuration from that tool. In the browser, this looks almost identical to genuine node-level hijacking, which makes it easy to misdiagnose as a node problem.

1. Check the system's certificate trust list

   On Windows, open Certificate Manager (certmgr.msc) and check "Trusted Root Certification Authorities." On macOS, open Keychain Access and check the login and system certificates for self-signed entries carrying the name of a debugging tool.

2. Remove or disable suspicious certificates

   Once you've confirmed a certificate came from a debugging tool you no longer use, remove it from the trust list or mark it as untrusted.

3. Check for leftover system-level proxy settings

   Some packet-capture tools write a fixed proxy address and port into the system network settings. After uninstalling the tool, manually clear these leftover settings to avoid conflicts with the Clash client's own proxy configuration.

Prioritized Troubleshooting Checklist

When you run into a certificate error, work through the steps below in order, starting with the ones that are cheapest and easiest to rule out:

1. Verify the system time and time zone

   This is the fastest thing to rule out — it takes only seconds to confirm or eliminate.

2. Disable the proxy and retest

   Fully quit the client and revisit the same site to determine whether the issue is proxy-related. If the error persists after disabling the proxy, the problem lies in the system's certificate trust list or the local hosts file, and has nothing to do with Clash.

3. Switch nodes and retest

   If disabling the proxy resolves the issue, switch nodes one at a time to check whether a single node is responsible for the hijacking.

4. Check the TUN-mode DNS configuration

   Confirm that enhanced-mode, nameserver, and dns-hijack are all properly set and that encrypted DNS is in use.

5. Check the system certificate trust list for suspicious entries

   Focus on self-signed root certificates left behind by previously installed debugging or packet-capture tools.

6. Update the client and rule subscriptions

   Make sure you're running a recent version of the Clash Meta (mihomo) core — known issues with TLS libraries or DNS handling in older versions may already have been fixed in later updates.