What Does a HTTPS Certificate Error Actually Mean?

When a browser visits an HTTPS website, it first establishes a TLS connection with the destination server. The server returns a certificate chain, which the browser checks for validity dates, issuing authority, domain coverage, and revocation status. If any check fails, the connection may be aborted and a certificate error displayed. Clash sits in the network forwarding path, but a standard system proxy, HTTP proxy, SOCKS5 proxy, or TUN forwarding does not automatically decrypt web traffic.

With an HTTP proxy, for example, the browser typically sends a CONNECT request to the local proxy port when visiting an HTTPS website, such as connecting to 127.0.0.1:7890, then asks to create a tunnel to example.com:443. Once the tunnel is established, the TLS handshake still takes place between the browser and the remote server. Unless an intermediate component performs HTTPS decryption, Clash cannot see the webpage plaintext or issue a certificate on behalf of the website.

What to Check for Each Browser Error Code

Error code Common meaning Priority checks
NET::ERR_CERT_DATE_INVALID The certificate is outside its validity period, or the local clock is significantly inaccurate System date, time zone, automatic time sync, and the website certificate's validity period
NET::ERR_CERT_COMMON_NAME_INVALID The certificate's covered domain does not match the domain being visited DNS poisoning, node-level hijacking, and incorrect hosts entries
NET::ERR_CERT_AUTHORITY_INVALID The certificate chain cannot be traced to a trusted root certificate Local traffic-inspection certificates, enterprise gateways, and certificate-store problems
ERR_SSL_PROTOCOL_ERROR The TLS handshake was interrupted, or the response was not valid TLS data Node availability, port forwarding, protocol settings, and network interception
SEC_ERROR_UNKNOWN_ISSUER Firefox cannot trust the certificate issuer Firefox's separate certificate store and local intermediate certificates

Why Does the Error Appear Only After Enabling Clash?

Enabling Clash changes the connection's exit point, DNS resolution path, and routing rules. If the error appears only after the proxy is enabled, that means the issue is related to the new path—not that the Clash core directly modified the certificate. For troubleshooting, break the path into six parts: browser, local proxy, rule matching, node, remote DNS, and destination server.

The node sent the request to the wrong server

If the node's exit uses abnormal DNS or the route is subject to domain hijacking, the destination domain may resolve to the wrong IP address. The browser may request account.example.com, while the remote server returns a certificate for another site, causing a domain mismatch. This usually affects only certain domains and often disappears immediately after switching to another node.

You can also inspect the certificate's “Issued to” field. If the current domain has no meaningful relationship to the certificate's Subject Alternative Name, focus on the node and DNS instead of clicking “Continue to site” in the browser. If a domain mismatch appears on a login page, payment page, or account portal, stop entering your username and password.

Local software performed HTTPS decryption

Charles, Fiddler, mitmproxy, some debugging proxies, enterprise endpoint-management tools, and security software can install a local root certificate and perform man-in-the-middle decryption of HTTPS traffic. When configured correctly, the browser trusts the temporary certificates issued locally. If the root certificate is missing, expired, or installed in the wrong certificate store, the issuer is shown as invalid.

A common path is the browser connecting to Clash, while Clash forwards traffic to another local proxy, or the operating system retaining an old PAC URL. Even when the Clash dashboard says the system proxy is enabled, traffic may pass through multiple processes. In Windows, go to Settings → Network & Internet → Proxy to check the manual proxy and setup script. On macOS, go to System Settings → Network → the current network → Details → Proxies to check the web proxy, secure web proxy, and automatic proxy configuration.

The system clock makes the certificate appear not yet valid or already expired

TLS certificates contain explicit Not Before and Not After timestamps. A one-day error in the computer's date, an incorrect time zone, or a clock that failed to sync after sleep can trigger NET::ERR_CERT_DATE_INVALID. Proxy activation and an incorrect clock may simply occur at the same time, especially after reinstalling the system, when the motherboard battery is low, or when a virtual machine is restored from a snapshot.

In Windows 11, open Settings → Time & language → Date & time, enable “Set time automatically” and “Set time zone automatically,” then click “Sync now.” On macOS, open System Settings → General → Date & Time and enable automatic time settings. After syncing, fully quit and reopen the browser rather than simply refreshing the current tab.

A Step-by-Step Clash Certificate Error Troubleshooting Checklist

The sequence below helps narrow down the cause quickly. Change only one variable at a time and record the result. Do not switch nodes, change DNS, reinstall certificates, and clear browser data simultaneously; otherwise, you will not know what actually fixed the problem.

  1. Record the complete error code. Do not write down only “Your connection is not private.” Copy the domain in the address bar, the browser error code, and the certificate issuer, and note when the error occurred.
  2. Disable the system proxy and test again. In the Clash client, turn off the “System Proxy,” fully quit the browser, and visit the same URL. If a direct connection works but the proxy fails, the likely causes are limited to the rule, node, or proxy path.
  3. Switch to a node on a different route. Prefer a node in a different region, from a different provider, or using a different protocol. After switching, wait 3–5 seconds for the old connection to close, then test in a private window.
  4. Temporarily switch the proxy mode to Global. If Global mode works but rule-based mode fails, the page's main domain, API domain, or static asset domain may be assigned to different exits. Switch back to rule-based mode after testing.
  5. Check the system clock. Verify the year, month, day, hour, minute, and time zone. Mainland China generally uses UTC+08:00; do not rely only on whether the taskbar clock looks close to the current time.
  6. Check the certificate issuer. Open the certificate details from the browser's address bar. If the issuer points to a local debugging tool, company gateway, or security product, investigate that program and its root certificate.
  7. Disable extra proxy layers. Quit traffic-capture tools, browser proxy extensions, and other proxy clients, and confirm that only one program is listening on the expected port.
  8. Check DNS and configuration files last. If only a few domains return an incorrect certificate, compare the resolved addresses on the direct and proxied paths, and verify that the rules are not sending those domains through the wrong exit.

Check Ports, Proxy Chains, and Local Listeners

Default ports vary by client. A commonly configured mixed port is 7890, the SOCKS port may be 7891, and the external control port is often 9090. These are only common values; use the current configuration and client settings as the source of truth. If the browser or system proxy points to an old port, it may connect to another process that is still running.

In Windows PowerShell, you can check which process is listening on a common port:

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess value>

On macOS or Linux, use the following command:

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:7891 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

If 7890 is occupied by an older client, debugging proxy, or another service, the current Clash client may automatically switch to another port or fail to start. Quit the conflicting process first, then open the client's Settings → Port Settings or Settings → Clash Settings and check Mixed Port, HTTP Port, and SOCKS Port. Menu names vary by client, but the port values must match those entered in the system proxy settings.

Check for an upstream proxy

mihomo configurations can route connections through another proxy using proxy providers, chained proxies, or mechanisms such as dialer-proxy. Browser extensions may also override the system proxy. For troubleshooting, keep the path as short as possible: let the browser use the system proxy, point the system proxy directly to Clash's Mixed Port, and have Clash use a known-working standard node. Once the path works, add relays and extensions one at a time.

When testing from the command line, you can compare the certificate information returned by a direct connection and the local proxy separately. The examples below send headers only and do not submit account data:

curl -I https://example.com/
curl -I --proxy http://127.0.0.1:7890 https://example.com/

If the direct request succeeds but the proxied request shows a certificate error, switch nodes and repeat the second command. If only one node fails, you usually do not need to change the system certificate store; disable that node and report the domain, time, and error code to the node provider.

How DNS, Rule Mode, and TUN Affect Certificate Results

Certificate validation is performed for a domain, but the connection ultimately reaches an IP address. Clash's DNS module, Fake-IP mode, rule-based routing, and the node's remote resolution together determine the actual destination. When these settings are inconsistent, the domain in the browser's address bar may remain unchanged while the server returns a certificate for another domain.

Inconsistent exits in rule-based mode

Modern webpages usually request the main site, login APIs, content delivery networks, and third-party resources at the same time. Sending the main domain through the proxy and the API domain directly does not automatically cause a certificate error, but different exits can return different addresses when regional restrictions, enterprise DNS, or geographically segmented CDNs are involved. Open the client's connection log, find the target domain at the time of the error, and confirm the matched rule and proxy group.

If temporarily switching to Global mode fixes the problem, add consistent rules for the same service domain. For example, when a main domain and its subdomains must use the same proxy group, add rules based on the actual domains:

rules:
  - DOMAIN,login.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

Rules are matched from top to bottom. More specific domain rules should come before broader rules. Do not copy example domains directly into a production configuration; use the connection log to confirm the actual requested domains.

Fake-IP and DNS hijacking

Fake-IP mode returns a mapped address to the local device, then the core applies rules and performs the real resolution based on the domain. Seeing an address in the 198.18.0.0/16 range in the browser does not mean the certificate was replaced; this is a common internal mapping method used by Clash. What matters is whether the core has correctly taken over the traffic and whether the destination domain has been placed in an unsuitable Fake-IP filter list.

TUN mode usually takes over traffic from more applications and can work with DNS hijacking to send queries on port 53 to the core. If an enterprise VPN, game accelerator, virtual machine network, or another TUN driver is running at the same time, routes and DNS may compete. For testing, temporarily disable TUN under the client's Settings → TUN Mode and keep only the system proxy enabled. If the certificate error disappears, inspect the routing table, DNS hijacking, and other virtual network adapters instead of importing an unknown root certificate.

Compare domain resolution results

On Windows, use Resolve-DnsName; on macOS and Linux, use dig. Query once with Clash disabled, then again after enabling it. Different results in Fake-IP mode are expected; use the Clash connection log to confirm the real destination. In Redir-Host mode, if the result is a completely different public IP address, check nameserver, fallback, the proxy node's remote resolution, and the local hosts file.

Resolve-DnsName example.com
nslookup example.com

dig example.com A
dig example.com AAAA

How to Handle Certificate Store and Browser Differences

Chrome and Edge generally use the operating system's certificate services, though implementation details vary by platform. Firefox can use its own certificate store, so Chrome may work while Firefox reports SEC_ERROR_UNKNOWN_ISSUER. If only one browser fails, first check that browser's extensions, proxy settings, certificate store, and security policies.

Checking certificates on Windows

Press Win + R, enter certmgr.msc, and view the certificates for the current user. In Trusted Root Certification Authorities → Certificates, look for certificates from traffic-inspection tools that are no longer in use. Do not bulk-delete system root certificates or import certificates based on an unfamiliar guide. If a certificate clearly belongs to an uninstalled debugging tool, consult that tool's removal instructions before deleting the certificate.

Checking the keychain on macOS

Open Applications → Utilities → Keychain Access and inspect both the “login” and “System” keychains. Search for the issuer name shown in the certificate details of the failing page, then check the certificate's validity period and trust settings. Devices managed by a company or school may receive certificates through a configuration profile; do not delete them yourself—ask the network administrator to verify them.

Firefox-specific checks

Open Settings → Privacy & Security → Certificates → View Certificates and review the list of certificate authorities. Also open Settings → General → Network Settings to confirm whether Firefox uses the system proxy, a manual proxy, or automatic proxy configuration. If the system proxy already points to Clash while Firefox is manually pointed to another port, Firefox is using a different path from other browsers.

Use the Clash Logs to Locate the Failure

When certificate validation occurs in the browser, the Clash log may not explicitly show “certificate invalid.” The log is more likely to provide the connection target, matched rule, node name, and underlying handshake error. During troubleshooting, temporarily set the log level to info or debug, reproduce the issue once, and restore it immediately to avoid generating excessive logs.

  • i/o timeout: The connection or handshake timed out. Check node quality, reachability of the destination, and the firewall first.
  • connection refused: The destination port or upstream proxy refused the connection. Check the port, protocol, and service status.
  • tls handshake timeout: The TLS handshake did not finish within the allotted time. Possible causes include packet loss, a faulty node, or restrictions on the destination.
  • remote error: tls: The remote side ended the TLS session. Check the surrounding log entries and destination domain.
  • no such host: Domain resolution failed. Check the DNS configuration, network reachability, and domain spelling.

If the log shows that the expected rule was matched and the request succeeds through another node, but the browser still displays a locally issued certificate, the problem is more likely between the browser and Clash. Conversely, if only one node produces a handshake timeout or an incorrect destination address, disable that node instead of weakening the browser's security settings.

Final Configuration Checks After Recovery

Once you find the cause, undo the temporary changes made during troubleshooting. Switch Global mode back to rule-based mode, restore the normal log level, disable unused manual proxies, and verify that TUN and the system proxy match your everyday needs. If you changed the rules, test at least the homepage, login API, and commonly used resource domains to confirm that they hit the intended proxy group.

Keep a backup of a verified working configuration and record the client name, core version, Mixed Port, DNS mode, and the node where the problem occurred. If a certificate error appears again, comparing these items is more effective than clearing all settings or reinstalling the client.