Browser Certificate Errors When Using a Proxy: HTTPS Causes and Troubleshooting

First, distinguish certificate errors from proxy connection failures

If your browser says “Your connection is not private,” HTTPS certificate validation has failed. This is different from a node timeout or a proxy port that is not listening. Clash Verge provides the client interface; the selected core handles traffic forwarding. In standard HTTP CONNECT and SOCKS proxy setups, Clash or Clash Meta (mihomo) typically does not decrypt the destination website’s HTTPS traffic and does not need a root certificate installed in the system to issue website certificates.

So, the fact that the warning appeared “after enabling the proxy” only indicates that a change in the network path may be related to the problem. It does not mean “the proxy client needs a certificate.” Note the browser error code, domain, certificate issuer, and validity period, then compare results across different connection paths. This is more useful for finding the cause than repeatedly reinstalling the client.

Step 1: Check your system time and certificate validity

Certificates have start and expiration dates. A computer left off for a long time, a failing motherboard battery, or a virtual machine restored from an old snapshot can leave the system date out of sync. Checking the hour in the taskbar isn’t enough—verify the year, month, and time zone too. If several unrelated websites show date errors, correct the system time first.

1. Windows 11: Go to Settings → Time & language → Date & time, turn on Set time automatically, confirm your time zone, and select Sync now. On organization-managed devices, use the time source specified by your administrator.
2. macOS: Go to System Settings → General → Date & Time, enable automatic date and time, and check the time zone.
3. Check the certificate: View the certificate details on the browser error page, or check the available certificate information in the Security panel of developer tools. Note the “Valid from” and “Valid to” dates and compare them with the corrected system date.

If only one website has an expired certificate and other sites work, the site operator likely needs to renew it or fix its CDN configuration. Changing your system date to fall within the certificate’s validity period can affect other websites and login tokens, so it is not a solution. Browsers validate against a specific point in time; changing only the displayed time zone may not correct an inaccurate system clock.

Step 2: Check for TLS interception and unexpected certificate issuers

Corporate gateways, security software with “HTTPS scanning,” and local packet-capture tools can terminate the original TLS connection and present their own certificate to the browser. If the current browser does not trust their root certificate, you may see an unknown issuer error. A captive portal on public Wi-Fi can also cause domain or issuer mismatches if its sign-in page is incorrectly returned for an HTTPS connection.

Compare certificates with and without the proxy

• In the same browser, record the certificate subject, SANs, issuer, and validity period for the same domain over both connection paths. A CDN may legitimately use different certificates, so a certificate change alone does not prove that traffic is being intercepted.
• If the issuer on the proxy path changes to an unfamiliar organization, router name, or local security product, check its HTTPS inspection feature and your network management policies.
• If every HTTPS site shows a certificate for the same unrelated domain, suspect a misconfigured gateway, captive portal, or traffic routed to the wrong service.

On organization-managed devices, ask your administrator where the organization’s root certificate came from, how it is distributed, and where it is used. On a personal device, if you’ve used a debugging proxy, check that it is no longer running and that no system proxy settings remain. Once you’ve confirmed you no longer need it, remove its configuration using the tool’s documentation. Don’t delete system certificates in bulk or remove trust settings managed by your organization.

Two different types of certificate validation

Browser validation of the destination website’s certificate and mihomo validation of an upstream TLS node’s certificate are separate steps. If the client log shows a node handshake failure, such as x509: certificate has expired, while the browser reports that the proxy connection was interrupted, contact your node provider about the certificate or server name configuration. The node setting skip-cert-verify does not fix browser warnings about the destination website; enabling it skips upstream identity verification instead.

Step 3: Check for DNS hijacking, incorrect resolution, and routing rules

An HTTPS connection has two steps: finding the server and verifying its identity. If DNS returns the wrong address, the browser may connect to a different server. If that server presents a certificate for another domain, the browser reports a name mismatch. A mismatch can also result from the website’s own CDN configuration, so verify over another trusted network rather than concluding that DNS is the cause just because changing DNS appears to help.

1. In Clash Verge, open the Connections page and filter by the affected domain to see the matching rule, policy group, and outbound route. Page names may vary by version; use the labels in your current interface.
2. Temporarily select a working node to prevent automatic policy switching from affecting the test. Note whether you’re using Rule or Global mode, then restore the original setting when you’re done.
3. Check dns, nameserver, fallback, and hosts in the active configuration. Subscriptions, overrides, or scripts may change the final configuration, so don’t rely on the original subscription text alone.
4. Check the system hosts file for an outdated mapping for the domain. The common Windows path is C:\Windows\System32\drivers\etc\hosts; on macOS and Linux, it is /etc/hosts.

With fake-ip enabled, an application seeing an address in the 198.18.0.0/16 range may be normal; the actual range depends on the configuration. The core maintains a mapping between domains and virtual addresses. Seeing a virtual address does not mean DNS has been hijacked, and fake-ip addresses do not need to be added to the browser’s trust list.

On Windows, run the commands below to check system DNS resolution and clear the system cache. However, browser Secure DNS, core DNS, and proxy-side DNS may use different paths, so nslookup alone cannot show which address the proxy connection actually used.

nslookup example.com
ipconfig /flushdns

If switching to a phone hotspot fixes the problem but it persists on the original network, check that network’s DNS, gateway, and authentication status. If a public network requires sign-in, use the network sign-in page provided by the system. Don’t enter account details on an HTTPS page with a certificate warning.

Step 4: Update root certificates and check the server’s certificate chain

An operating system that hasn’t been updated for a long time may lack a trusted root certificate used by the site. Some browsers use their own trust store or a hybrid trust model, so it’s not unusual for one browser to work while another fails on the same device. Older browsers may also lack support for the site’s current certificate chain or TLS features.

• Unknown issuer errors on multiple websites: Install operating system security and browser updates. Check that a policy hasn’t blocked trust store updates, then restart the browser and test again.
• Only one website is affected: The server may be missing an intermediate certificate. Some browsers can use a cached certificate or retrieve a missing link in the chain, while a new device may fail. The site operator needs to fix the complete certificate chain.
• Only one browser is affected: Check its version, enterprise policies, and certificate management settings. Don’t import every certificate into every browser.
• Your operating system no longer receives security updates: Upgrade to a supported version instead of downloading a root certificate bundle from a forum and importing it wholesale.

“The certificate has expired” may refer to the leaf certificate, or to a chain-building problem involving an intermediate or root certificate. The brief message on an error page may not identify which one; check which certificate in the chain failed. You normally don’t need to manually import a website’s leaf certificate to access it.

Narrow down the problem by comparing direct and proxy connections

The examples below use 7897 as the local HTTP mixed port; your setup may use a different port. Confirm the actual value in the client settings or the active configuration’s mixed-port field. If the core isn’t running, the command will fail to connect before it reaches the website’s certificate validation stage.

Windows: Test without disabling certificate validation

curl.exe --noproxy "*" -I https://example.com/
curl.exe --noproxy "" --proxy http://127.0.0.1:7897 -I https://example.com/

Replace example.com with the affected domain. The first command bypasses curl’s explicit proxy settings; the second clears the no-proxy list and specifies the local HTTP proxy. On macOS or Linux, replace curl.exe with curl. Add -v to see handshake details. Don’t add -k, which skips certificate validation.

curl and browsers may use different TLS libraries and trust stores, so test results are clues for troubleshooting, not a final security verdict. Before sharing logs, remove subscription URLs, access tokens, proxy credentials, and private domains. Full subscription links often contain credentials that grant access to the subscription.

Restore settings and run a final check

Change one variable at a time: correct the clock first, then compare certificates, check DNS and the outbound route, and finally address the trust store or server certificate chain. Changing nodes, disabling DNS, switching modes, and installing certificates all at once makes it impossible to tell what actually fixed the problem.

1. Restore your usual rule mode, policy groups, TUN, and system proxy settings, and remove any temporary rules added during troubleshooting.
2. Reopen the browser and visit the affected domain and two unrelated HTTPS websites. Confirm that no certificate warnings appear.
3. Confirm that the original website’s certificate SAN includes the domain you visited, the certificate is currently valid, and the browser trusts the certificate chain.
4. If the problem occurs only on a specific outbound route, send the service provider the domain, time of occurrence, error code, and sanitized logs. If only one website is affected, report the certificate chain issue to its operator.

The goal when fixing a certificate error is to restore correct server identity verification—not just dismiss the warning. Troubleshooting is complete only when the system time is correct, the certificate matches the domain, the certificate chain is trusted, and traffic is following the expected route. For more on proxy modes, subscriptions, and rule fields, see the Configuration Reference. For common connection issues, visit Troubleshooting.