HTTPS Certificate Errors When Using a Proxy: Causes and Fixes

First, identify the failure: a website certificate error or a proxy node handshake failure

An HTTPS error after enabling Clash doesn’t necessarily mean Clash changed the website’s certificate. Standard HTTP CONNECT and SOCKS proxies, as well as TUN forwarding, usually relay connections without decrypting HTTPS traffic between your browser and the website. First pinpoint where the connection fails, then decide whether to check your browser, system trust store, or node configuration.

Browser error codes have limits, too. ERR_SSL_PROTOCOL_ERROR indicates a TLS protocol error; it doesn’t prove that a certificate was replaced. It can also occur if an HTTPS request is sent to a regular HTTP service, the server’s TLS configuration is faulty, or a network device interrupts the handshake.

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

Certificates have start and expiration dates. If your computer’s clock falls outside that period, you may see an error even when connecting to the correct server. Time can drift after waking from sleep, because of a failing motherboard battery, or when a virtual machine isn’t syncing its clock. Check the time first—it’s more direct than changing DNS or reinstalling the client.

1. Windows 11: Go to Settings → Time & language → Date & time. Turn on Set time automatically, check your time zone, then select Sync now.
2. macOS: Go to System Settings → General → Date & Time and check that automatic date and time are enabled. If you need to make changes, follow the system’s authorization prompts.
3. Android: Search Settings for “Date & time” and turn on automatic time and time zone. Menu names and locations vary by manufacturer.
4. iOS: Go to Settings → General → Date & Time and check Set Automatically. If device management policies prevent changes, contact your administrator.

In your browser’s certificate warning details, look for the certificate viewer and note the “Valid from,” “Valid until,” and “Issuer” fields. In desktop Chromium browsers, you can also find certificate details in the developer tools’ Security panel. The exact labels and location vary by browser version.

If your device’s date is correct and only one site has an expired certificate, the site owner needs to renew it. Switching nodes won’t make an expired certificate valid again. If the issue occurs only with one node, check whether its exit route is connecting to a different server.

Step 2: Compare a direct connection with a proxy using the same URL

Use the exact same URL for each comparison, including the domain and path. Change only one variable per test, and record the error code, certificate issuer, and matched rule. Don’t change the node, DNS, browser, and network all at once; if the issue disappears, you won’t know why.

A four-step comparison

1. Record the current setup: Note the client mode, selected node, system proxy, and TUN status. Check the Connections list for the domain to confirm which policy is actually being used.
2. Test a direct connection: Turn off the system proxy and TUN. Check that no browser proxy extension, manual proxy, or other VPN is still routing traffic. Visit the same URL and record the result.
3. Re-enable the proxy: Restore the original settings and select node A. Confirm in the Connections list that the request went through node A, rather than matching DIRECT.
4. Switch only the node: Change to node B, leave all other settings unchanged, and check the error code and certificate details again.

If the direct connection works, node A fails, and node B works, the issue is more likely related to node A’s exit route, DNS resolution, or server configuration—but this test alone doesn’t prove interception. If both direct and proxy connections fail, check the device time, website certificate, system trust store, and local network first.

Some sites can’t be reached directly on your current network, so a direct-connection timeout doesn’t mean the certificate is valid. You can compare results using another trusted network or device, but note what changed. A successful connection from another device doesn’t prove that your local configuration is correct.

Use commands to verify the local proxy route

If the client’s mixed port is 7890, run the following commands in Windows Terminal. On macOS or Linux, use curl instead of curl.exe. The example domain illustrates the command syntax; when troubleshooting, replace it with the domain where the error occurs.

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

The first command bypasses curl’s explicit proxy settings, but it won’t bypass TUN or other network-level routing on your system. Turn those off before running it. The second command explicitly uses the local HTTP proxy; check the port shown in your client. Different curl builds and browsers may use different trust stores, so different results aren’t necessarily a contradiction.

Step 3: Check for TLS interception and identify the source of root certificates

Corporate gateways, antivirus HTTPS scanning, and packet capture tools may terminate TLS on your device or network, then present the browser with a newly issued certificate. If the device trusts the tool’s root certificate, the browser may show no warning. If that root certificate is missing, expired, or untrusted by the browser, you may see an error saying the issuer isn’t trusted.

Check the certificate chain before changing the trust store

• Check the domain: Look at the certificate’s Subject Alternative Name (SAN) and confirm it includes the hostname in the address bar. Don’t rely only on the certificate’s display name or organization.
• Check the issuer: If it shows the name of a corporate gateway, packet capture tool, or security product, check whether that matches your installed tools and organization’s policies. The name alone doesn’t prove the certificate is trustworthy.
• Check the scope: If multiple unrelated sites suddenly show certificates issued by the same local authority, and this happens only on one device or network, check for a shared HTTPS inspection tool.

On Windows, press Win + R, run certmgr.msc, and check Certificates under “Trusted Root Certification Authorities” for the current user. For computer-level certificates, use the appropriate management console. On macOS, open Keychain Access, select the System or Login keychain, and review the certificates and trust settings.

These tools help identify where a certificate came from; they aren’t instructions to delete certificates in bulk. Certificates on managed devices may be required for work, so ask your administrator to verify them. On a personal device, if you recently used a packet capture tool, follow its instructions to stop HTTPS decryption and revoke its trust, then test again. Don’t install a so-called “Clash root certificate” from an unfamiliar download page; standard proxy forwarding doesn’t require one.

Step 4: Distinguish DNS problems from node TLS configuration errors

Why DNS problems can look like certificate errors

If DNS points a domain to the wrong address, the browser still checks the requested domain against the certificate. If the wrong server returns a certificate for a different domain, you may see a name mismatch; if it drops the connection, the result may look like a handshake failure. DNS doesn’t issue certificates, so check the resolution result, connection destination, and certificate SAN together.

On Windows, run Resolve-DnsName example.com to check the system’s DNS result. On macOS or Linux, nslookup example.com can help. However, the browser’s Secure DNS, mihomo’s built-in DNS, and DNS resolution by the proxy server may use different routes. The result of a system command may not match the result the browser actually uses.

• Check the Connections and Logs views in your client for the destination domain, matched rule, and exit policy to confirm where the request went.
• Check dns, nameserver, nameserver-policy, and TUN DNS hijacking settings in the active configuration. Make sure you’re not editing a file that hasn’t been loaded.
• If you use fake-IP, an address in the 198.18.0.0/16 range doesn’t necessarily indicate DNS pollution. mihomo commonly uses 198.18.0.1/16 as its default fake-IP range. These addresses are for internal mapping, not a website’s real exit address.
• After changing DNS policies, establish a new connection and test again. Existing connections and cached results may still use the previous settings. Don’t start by replacing every DNS entry with the same public resolver.

A node certificate error occurs on a different connection

With proxy protocols that use TLS, the client also verifies the proxy server’s certificate. This is separate from the browser’s verification of the website certificate. If the logs show the node server as the destination and the browser reports a tunnel connection failure, first check the server address, port, and TLS settings provided by your subscription provider.

For a common mihomo TLS node configuration, server is the address to connect to, and port is the server’s listening port. Some protocols use servername to specify the TLS server name; other configuration types use sni. Which fields apply depends on the protocol and core support—don’t copy settings from one protocol to another.

Match the fix to the scope of the error, and keep records that allow it to be reproduced

At this point, narrow down the issue based on how widely it occurs. Restoring access is only part of the solution: make sure you haven’t left behind an incorrect trust setting or a temporarily disabled verification option.

Public Wi-Fi may require you to sign in through a captive portal first. Use the network sign-in prompt opened by your operating system; don’t bypass an HTTPS certificate warning to enter your credentials. If you can’t verify the network, disconnect and use a trusted connection.

What to include when reporting the issue

• Your operating system, browser and client versions, and core name. Find these under About or on the core information page.
• When the error occurred, the destination domain, the browser’s full error code, and the certificate’s SAN, issuer, and validity dates.
• Results for a direct connection, node A, and node B, and whether the system proxy and TUN were enabled.
• Relevant logs from before and after the error. Redact subscription links, node passwords, tokens, account details, and any addresses you shouldn’t share publicly.

If your operating system or browser is out of date, install supported security updates through official update channels, then test the certificate chain again. Before switching clients, note your current port, rule mode, and TUN status so you can distinguish installation changes from network issues. For basic settings, see the system proxy guide. For DNS issues, see the DNS troubleshooting guide.

A safe troubleshooting order is: record the error, correct the system time, compare connection routes, check the certificate’s source, then investigate DNS or node settings. Keep certificate verification enabled throughout, and don’t treat “the page loads now” as the only measure of success.