Clash Certificate Errors: Fix NET::ERR_CERT Warnings

First, identify the problem: a certificate error isn’t a connection timeout

Check your system clock first, note the certificate details, then compare the proxy and TUN routes. When your browser shows NET::ERR_CERT_AUTHORITY_INVALID, the certificate it received failed trust validation. This is different from a node timeout or an expired subscription. Switching nodes may change what you see, but it doesn’t replace checking the certificate.

A standard Clash or Clash Meta (mihomo) proxy connection usually just forwards HTTPS traffic; it doesn’t issue a new certificate for the site you’re visiting. With an HTTP proxy, the browser can establish a tunnel using CONNECT, then complete the TLS handshake with the destination site. The browser still validates the site’s certificate. You don’t need to install a so-called “Clash root certificate” to use a Clash client normally.

Record these five details first

• The full domain in the address bar and the error code shown on the warning page. Before sharing, remove tokens and personal parameters from the URL.
• The certificate’s issuer, validity dates, and Subject Alternative Names (SANs). Depending on the browser, open the advanced details on the warning page or use its certificate viewer.
• How widespread the issue is: one domain, several domains from the same organization, or nearly every HTTPS site.
• Clash’s current mode, the node actually selected, and whether the system proxy and TUN mode are enabled.
• Whether you enabled packet-capture software, updated security software, or joined a network that requires sign-in, such as hotel or airport Wi-Fi, before the issue began.

Narrow down the cause by error code

Chrome, Edge, and other Chromium browsers use similar error codes; Firefox may phrase them differently. A code tells you which part of validation failed, but doesn’t prove which app caused it. Check the table below, then follow the steps.

ERR_SSL_PROTOCOL_ERROR isn’t necessarily a certificate trust error. It can also result from a service running on the wrong port, a failed TLS negotiation, or interference from network equipment. Don’t assume every error containing “SSL” means a root certificate is missing.

Step 1: Check your system clock and the certificate’s validity dates

If your device clock is set too far ahead or behind, a valid certificate may appear not yet valid or expired. If unrelated sites all show date errors, check your device first instead of changing rules across the board.

1. In Windows 11, open Settings → Time & language → Date & time. Check that Set time automatically is on, then select Sync now. Make sure the date, year, and displayed time are correct.
2. On macOS, open System Settings → General → Date & Time. Check automatic date and time settings, as well as the time zone.
3. After syncing, quit the browser completely and relaunch it. Reopen the URL instead of just refreshing the existing error page.
4. If only one site still fails, check the certificate’s start and end dates. If the server certificate has actually expired, the site operator needs to renew it.

Quick checks from the Windows command line

Get-Date
w32tm /query /status

Use these commands in PowerShell to check the current time and Windows Time service status. The second command may return an error if the service isn’t running. The time zone mainly affects how the time is displayed; certificate validation depends on the actual system time. Don’t change only the time zone and overlook the date. If the clock resets whenever the device loses power, check the firmware time and hardware clock too.

Step 2: Check HTTPS inspection and packet-capture proxies

When HTTPS decryption is enabled, debugging tools such as Charles and Fiddler present the browser with site certificates signed by their local root certificate. Some security software’s HTTPS scanning and enterprise gateways use a similar approach. Warnings can occur if the current browser doesn’t trust the root certificate, the certificate has expired, or proxy settings remain after the tool is uninstalled.

Start by checking the certificate issuer

• If certificates for several unrelated sites are issued by the same local debugging tool or organization, check the proxy in between before suspecting the sites themselves.
• Temporarily quit any packet-capture tools you installed and turn off their HTTPS decryption. Then check whether the system still points to one of their listening ports.
• In Windows 11, check for a manual proxy under Settings → Network & internet → Proxy. On macOS, go to System Settings → Network → your current connection → Details → Proxies.
• Also note Clash’s actual mixed-port value. 7890 is just a common example, and another process could be using it. The system proxy address should match the listening address shown in the current client.

On a personal device, if the problem occurs in only one browser, compare it with another up-to-date browser. Browser versions, root certificate stores, and management policies can differ. If another browser opens the site, that only shows the validation environments differ—it doesn’t mean the unusual certificate is safe to trust.

Step 3: Check DNS, the hosts file, and network sign-in pages

DNS doesn’t issue HTTPS certificates, but an incorrect DNS result can send the connection to a different server. If you request one domain and receive a certificate for another, the names won’t match. Check for captive portals on public Wi-Fi, old entries in your hosts file, and incorrect DNS mappings.

Handle network sign-in first, then check name resolution

1. If you’ve just joined hotel or airport Wi-Fi, use the sign-in page provided by the network to complete authentication. Don’t enter your credentials on a certificate warning page.
2. Check the hosts file for an outdated mapping of the affected domain. On Windows, the file is at C:\Windows\System32\drivers\etc\hosts; on macOS and Linux, it’s usually /etc/hosts.
3. On Windows, use the commands below to check the system’s DNS lookup results and clear its cache. Then restart the browser and check Clash’s own DNS cache and connections as well.

nslookup example.com
ipconfig /flushdns

example.com is a placeholder for the command format; use the domain that’s actually failing when you troubleshoot. Note that nslookup may not use the same resolution path as your browser: browser Secure DNS, proxy-side DNS resolution, and TUN DNS interception can all change the result. Command output alone can’t prove which address the browser connected to.

Don’t assume a Fake-IP address means DNS is poisoned

In Fake-IP mode, mihomo may return a mapped address in the 198.18.0.0/16 range to the app, then map it back to the original domain. This range is common, but not universal across clients. Seeing one of these addresses doesn’t mean you’ve connected to a spoofed site. Check the active configuration’s dns.enhanced-mode and fake-ip-range, along with the connection logs.

If the direct route receives the wrong certificate while the proxy route works, then investigate local name resolution, your internet provider’s network, and the direct server. Don’t change an HTTPS URL to an IP address for testing: certificates are usually issued for domain names, so visiting an IP can cause a name mismatch on its own.

Step 4: Test the system proxy and TUN mode separately

TUN mode usually takes over traffic at the network layer; it doesn’t inherently decrypt TLS. If the problem starts only when TUN is enabled, it may have changed routing, DNS handling, or rule matching, sending the connection down a different path. Conflicts with another VPN, virtual network adapter, or security app are also possible.

Test one variable at a time

1. Record a baseline: Note the current mode, node, DNS settings, and certificate details from the error. Keep the same node throughout testing, and don’t update the subscription or change rules at the same time.
2. Test the system proxy: Turn off TUN and enable the system proxy. Quit the browser completely, then reopen it. Make sure no extension or organization policy is directing the browser to a different proxy.
3. Test TUN: Turn off the system proxy, then enable TUN. Use the same domain and node. Check the connection log in Clash for the matched rule, outbound policy, and destination details.
4. Test a direct connection: Turn off both the system proxy and TUN, and make sure no other VPN or manual proxy is handling the connection. Reconnect, then compare the certificates—not just whether the site opens.

If only the TUN route fails, start by checking DNS interception, conflicts with other VPNs, and virtual network adapters. If the system-proxy route fails too, compare the certificate issuer and the node actually in use. Back up your configuration before making changes, and change only one thing at a time. Subscription updates may overwrite direct edits; for persistent changes, use the client’s supported override or merge mechanism. Check the specific fields against your current mihomo version.

Compare routes with curl and keep the validation results

The examples below use 7890 as the local HTTP or mixed proxy port. Confirm the port in the client’s settings first. In Windows PowerShell, use curl.exe to avoid conflicts with an alias that may have the same name.

curl.exe -Iv --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -Iv --noproxy "*" https://example.com/

On macOS and Linux, replace curl.exe with curl. The first command explicitly uses an application-layer proxy; the second skips curl’s application-layer proxy settings. The second command does not bypass TUN or other network-layer traffic interception on your system. To test a direct local connection, you still need to turn those features off first.

• Compare TLS validation results, the certificate subject, and the issuer. How much certificate information curl displays depends on its version and TLS backend.
• curl exit code 60 usually indicates certificate verification failed. Read the specific reason that follows; don’t assume it’s a DNS problem.
• Don’t add -k or --insecure, or you’ll skip the very validation step you’re investigating.
• curl and your browser may use different trust stores, so curl succeeding doesn’t automatically mean the browser’s trust settings are fine. A 405 response to a HEAD request also doesn’t mean the TLS handshake failed.

Before sharing logs, remove proxy credentials, cookies, subscription URLs, and request parameters containing tokens. The test time, error code, and certificate issuer are usually more useful for troubleshooting than a full configuration file.

Choose the next step based on how widespread the issue is

Every website shows an error

Check the system clock, root certificate updates, packet-capture tools, and network sign-in first. Keep your operating system and browser supported and up to date; older systems may lack newer certificate chains in their trust stores. Don’t download root certificate “fix packs” from untrusted sources.

Only one website shows an error

Compare the site on another device and network. If both show the same expired certificate or name mismatch, contact the site operator. If the error occurs only on one node, note the node and certificate details, test another trusted node, and report the issue to your service provider.

How to confirm the issue is fixed

• The domain that showed the original error and at least two other sites all pass normal certificate validation.
• The certificate covers the domain you’re visiting, has reasonable validity dates, and no root certificate from an unknown source has been added.
• After restoring your usual rules mode, the outbound policy in the connection logs matches what you expect. The results remain consistent after restarting the client and browser.

The fix should address the specific problem with the system clock, trust chain, name resolution, or connection route—not hide the browser warning. For details on checking modes and subscription updates, see the Clash Configuration Manual. For client installation and initial setup, follow the Setup Guide.