Clash HTTPS Certificate Errors After Using a Proxy: Causes and Layered Troubleshooting

After enabling Clash's system proxy or TUN mode, a browser may suddenly show messages such as “Your connection is not private,” “Unknown certificate authority,” or “Certificate name mismatch,” making it tempting to blame the client. In practice, start by separating two questions: whether the proxy sent traffic along a different path, and where the HTTPS connection terminated. Standard Clash and the Clash Meta (mihomo) core generally forward connections and choose an egress according to rules; they do not normally decrypt ordinary websites' TLS traffic on the local machine. Unless the configuration adds traffic sniffing, scripts, or a man-in-the-middle proxy component, the certificate shown by the browser should still come from the destination site.

Common causes of certificate errors include an incorrect system clock, a misconfigured website certificate chain, incorrect DNS results, a proxy exit returning a block page, HTTPS inspection on a corporate or institutional network, security software injecting a local certificate, or a browser using a separate certificate store. The right approach is not to keep switching nodes, but to record the error first and use controlled comparisons to establish where the failure begins.

1. Understand HTTPS certificates and Clash's role

When visiting an HTTPS website, the browser checks the certificate's domain name, validity period, issuing chain, and intended use. The certificate must cover the hostname being visited, the current time must fall within its validity period, and the chain must ultimately lead to a root certificate trusted by the system or browser. If any check fails, the browser blocks the connection or displays a warning.

Clash's system proxy usually lets applications that support system proxy settings send HTTP or SOCKS connections to a local listening port; TUN mode uses a virtual network interface to capture more IP traffic. These modes change the connection entry point and routing scope, but do not automatically replace a website's certificate. A proxy node or upstream network can still alter DNS results, block the destination, or return an authentication or warning page. The browser is still visiting the same domain, but the response comes from another server, which can appear as a certificate name mismatch or an unexpected issuer.

The relationship between TLS certificates and subscription URLs also needs to be clear. A subscription only supplies the client with proxy nodes, policy groups, and rules. If downloading a subscription produces a certificate error, check the subscription domain, system time, and network path separately; this does not show that every node has failed. Conversely, a successful subscription update only proves that the URL is reachable—it does not prove that every destination website has a valid TLS chain.

2. Narrow the scope with four comparison tests

Before troubleshooting, pause activities involving account sign-in, payments, or administrative consoles. Then choose one normally reliable HTTPS site and one site that produces the error, and run the comparisons below. Change only one condition at a time; switching the browser, node, DNS, and TUN mode together makes the results impossible to interpret.

1. Compare proxy enabled and disabled: Turn off Clash's system proxy and TUN mode, then try again. If direct access works but the proxy path fails, focus on the node's egress, matched rules, DNS, and intermediary devices. If both states fail, check the system clock, browser certificate store, and destination site first.
2. Compare one website with all websites: If only one domain fails, the issue is usually related to that site's certificate, DNS resolution, or a specific rule. If many unrelated sites fail at once, a shared problem with the local clock, root certificate store, institutional network inspection, or security software is more likely.
3. Compare one browser with all applications: If only one browser fails, check its security policies, extensions, DNS-over-HTTPS settings, and separate certificate store. If the browser, command-line tools, and other applications all fail, the problem is more likely in the system or network path.
4. Compare the current network with a backup network: Where permitted and appropriate, switch to another trusted network. If the error occurs on a corporate or campus network but not elsewhere, an authentication portal, gateway inspection, or egress policy may be involved. If every network behaves the same way, return to the local machine and configuration layers.

During testing, confirm which rule Clash actually matched in its dashboard. One domain may use the proxy while its images, APIs, or login domains use a direct connection. The main page loading does not mean that every HTTPS request used the same egress. If developer tools show a certificate failure for only one subdomain, record the complete hostname and then check which rule and policy group matched it.

3. Check the system, browser, and network layers

1. Correct the system date, time, and time zone

Certificate validation depends on an accurate clock. A failing motherboard battery, a suspended virtual machine, switching between operating systems, or manually setting the time zone can cause the clock to drift by hours or even years. Enable automatic date and time, then run a time synchronization; also verify the time zone instead of checking only the hour shown in the taskbar. After correcting the clock, fully quit and restart the browser so it establishes fresh TLS connections.

If the time becomes incorrect again after every reboot, fix the system time source or hardware clock instead of continually adding browser exceptions. Messages such as “not yet valid” and “expired” can both be caused by the local clock, so do not assume the certificate is actually invalid based only on the page text.

2. Check the certificate domain and issuing chain

Open the certificate viewer provided by the browser and record the “Issued to,” “Issued by,” validity period, and certificate path. If the domain being visited does not match the domains covered by the certificate, common causes include DNS pointing to the wrong server, a transparent gateway returning an authentication page, or an incomplete website deployment. If the issuer is named after an organization, security product, or local network device, the connection may be passing through HTTPS inspection. Whether that certificate should be trusted must be confirmed by the device or network administrator.

When the certificate path is missing an intermediate certificate, some browsers may complete the chain from cache while other applications fail immediately. This can explain why a browser works but a command-line tool fails, or vice versa. Repair the server's certificate chain or update the system certificate store and application runtime; disabling certificate verification is not a suitable long-term solution.

3. Compare browser policies and certificate stores

Different browsers may use the system certificate store or maintain additional trust policies. Enterprise management policies, parental controls, security software HTTPS scanning, and older runtimes can all affect the result. First use a guest profile or new test profile to rule out extensions, then check whether the browser reports that it is “managed by your organization.” If the device belongs to an organization, follow its official administrator guidance rather than deleting organizational certificates yourself.

Browsers with encrypted DNS enabled may also bypass the DNS setup in Clash, causing different applications to resolve the same domain differently. During troubleshooting, temporarily make the browser use the system resolver, then compare the result with Clash's DNS logs. The goal is to identify the resolution path, not to assume that one DNS method is universally better.

4. Rule out authentication portals and intermediary devices

Hotels, airports, campuses, and guest networks often require web authentication first. Before the device is authenticated, a gateway may redirect requests to a login page; HTTPS cannot be redirected as smoothly as ordinary HTTP, which can trigger a domain mismatch. Turn off the proxy and, after confirming that the network is trustworthy, open the network's authentication portal and sign in. Then restore Clash.

Router content filters, family-safety features, corporate gateways, and endpoint protection software may also inspect encrypted connections. If the issuer suddenly changes to the name of a local product and the issue disappears when the managed network or product is disabled, investigate that product's management policy. Installing a root certificate from an unknown source expands the trust boundary and is not an appropriate quick fix.

4. Check Clash rules, DNS, nodes, and TUN

Confirm the matched rule and policy egress

Find the failing domain in the Clash client's connection log and see whether it matched a direct, proxy, or reject rule. Rules are matched from top to bottom; an earlier domain, suffix, or rule set may override later settings. If the destination was sent to an unsuitable egress, temporarily switch to an explicit policy to verify the cause, then correct the rule order in the configuration. Do not rely on global mode indefinitely to hide a rule problem.

A single service often uses several domains for login, static assets, APIs, and certificate-status checks. Changing only the main page domain may not be enough. Use the connection log to determine whether related domains were split across different egresses, especially when the error appears only after a login redirect. For a complete explanation of rules and policy groups, continue with the user guide.

Verify DNS resolution results

If the certificate name mismatch appears only when the proxy is enabled, DNS is an important checkpoint. Clash Meta (mihomo) can use different DNS upstreams, rule-based resolution, and modes such as fake-ip or redir-host. The configuration itself does not create a false certificate, but an incorrect upstream response, poisoned result, stale cache, or mismatched split-routing path can send the domain to the wrong address.

Start by checking query results and connection targets in the Clash logs. If necessary, clear the operating system and browser DNS caches, then test again. With fake-ip configured, rely on Clash's internal mappings and final connection records; do not mistake a reserved fake-ip address for the website's real server. After changing DNS, restart the core or reload the configuration so old connections and cached results no longer affect the test.

Use node switching only to isolate the cause

If only one node causes the certificate error under the same configuration while other trusted nodes work, the problem is associated with that egress or its upstream path. Record the node, destination domain, and time, then stop using that route. If every node fails while direct access works, continue by checking shared DNS settings, rule providers, chained proxies, and local intermediary software.

Normal latency does not guarantee that TLS works. A latency test usually checks only the response speed of one address; it does not cover the destination site's certificate chain, SNI, DNS result, or complete page requests. Do not treat a node displaying a latency value as proof that the certificate issue has been ruled out.

Test system proxy and TUN mode separately

If the system proxy works but TUN mode fails, focus on TUN DNS hijacking, routes, permissions, and other virtual network adapters. If TUN works but the system proxy fails, check whether the application correctly reads system proxy settings, whether the browser uses separate proxy settings, and whether another program occupies the local listening port. Stop active downloads and sign-in operations before switching modes, then establish fresh connections afterward.

Do not run multiple proxy clients, browser proxy extensions, and duplicate TUN software at the same time. They can create a proxy chain or loop, sending traffic through several local ports in succession. During troubleshooting, keep one clearly defined entry point and confirm that the HTTP, SOCKS, or mixed port in the client matches the system settings. For the basic setup, see the Clash user guide.

5. How to interpret common browser error codes

The wording of error codes differs slightly across Chrome, Edge, Firefox, and Safari, but the diagnostic dimensions are the same. When reviewing a code, also record the URL and certificate details. If the page has redirected from the original domain to an authentication page or another domain, the issue may be part of the network login flow. If the URL stays the same but the certificate belongs to an entirely unrelated domain, stop accessing the site and check DNS resolution and intermediary devices.

6. Safe handling boundaries and a final checklist

A certificate warning is the browser's assessment of the connection's identity; permanently disabling HTTPS verification is not an appropriate way to remove it. Skip-verification options in command-line tools, forced “Continue” links in browsers, and manually trusting unknown root certificates can remove important protection from later connections. Testing can help locate the cause, but it should never require submitting a password, verification code, or payment information.

If the destination site's certificate has expired or its chain is misconfigured, the client can usually only wait for the site owner to fix it or contact the maintainer. If the issue comes from a managed device, the organization administrator should confirm the root certificate and inspection policy. If it is limited to one node, stop using that route and report the domain, time, and error type to the service provider. If the cause is the local clock, DNS cache, duplicate proxy, or an incorrect rule, correct it, reload the configuration, and retest the original failing site.

Check these once more before resuming use

• The system date, time, and time zone are correct, and automatic synchronization is working.
• The domain in the browser address bar matches the certificate's coverage.
• The certificate issuer is expected, and the chain leads to a trusted root.
• The rules, policy group, and actual egress in the Clash connection log match the intended configuration.
• The DNS resolution path is clear, with no unexpected difference between browser and system upstreams.
• System proxy and TUN are not competing with other proxy tools or virtual network adapters.
• Test results after changing networks or nodes have been recorded, allowing the issue to be reproduced consistently or confirmed as resolved.

After applying a fix, first verify it with an ordinary public page, then test the domain that originally failed. If the page involves sign-in, confirm that the URL, certificate issuer, and connection status are all normal before entering any information. Certificate issues may appear to be confined to a browser warning page, but the real cause can span time, DNS, rules, egress, and network management. Changing one variable at a time is usually faster than repeatedly reinstalling the client.