Clash HTTPS Certificate Errors: Troubleshoot Proxy Chains, System Time, and Certificate Trust

First, identify where the certificate error occurs

When Clash is enabled, a browser may show “Your connection is not private,” “Unknown certificate authority,” “Certificate name mismatch,” or a failed TLS handshake. That does not necessarily mean the Clash client modified the website’s certificate. A standard HTTP CONNECT or SOCKS5 proxy usually only establishes a transport channel to the target server; HTTPS encryption and certificate validation still take place between the browser and the destination website. Under normal conditions, the certificate shown by the browser should still be issued to the target website by a trusted certificate authority.

Clash, Clash Meta (mihomo), and clients built on these cores do not require a general-purpose root certificate for ordinary HTTPS traffic simply because system proxy or TUN mode is enabled. If the issuer suddenly changes to a corporate gateway, security scanner, router, or unfamiliar organization, inspect the upstream proxy and local network intermediaries first instead of immediately deleting the subscription or reinstalling the client.

Before troubleshooting, note three things: which websites fail, whether closing Clash restores access immediately, and whether another device on the same network shows the same error. A single failing site is more likely to indicate a site certificate, DNS, or rule-routing issue. Widespread failures more often involve system time, certificate stores, upstream proxies, or network inspection devices. If only one browser fails, focus on that browser’s certificate store, extensions, and security settings.

Common errors and what to check first

Certificate not yet valid or expired: Check the system date, time, time zone, and automatic time-sync status first.
Certificate authority not trusted: Check whether the certificate chain is complete and whether corporate HTTPS inspection or local filtering software is present.
Certificate name mismatch: Check DNS resolution, transparent gateways, captive portals, and rule-routing results.
Handshake failure or protocol error: Check node availability, upstream protocol parameters, TLS Server Name, network blocking, and client logs.
Only some subresources fail: Use the browser developer tools to identify the exact failing domain, rather than mistaking a third-party API outage for a certificate problem on the main site.

Check system time, time zone, and automatic synchronization

TLS certificates have explicit validity and expiration times. If the device clock is off by hours, days, or years, the browser may treat a valid certificate as not yet valid or expired. A laptop that has been powered off for a long time, a faulty motherboard clock, suspended and resumed virtual machines, dual-boot systems, and manually changed time zones can all cause this. If the errors appear only after enabling the proxy while visiting sites the device had not accessed recently, Clash may be blamed incorrectly.

Confirm that the system date, time, and time zone are accurate, paying particular attention to whether the UTC offset matches your location.
Enable automatic date and time and automatic time-zone settings, then manually trigger one time synchronization.
Fully quit and reopen the browser so that an old TLS session or error page does not remain in the tab.
If automatic synchronization fails, temporarily disable the proxy and try syncing again. Also check whether the time service is being routed incorrectly by a rule.

Checking the time on Windows

In Windows Settings, open “Time & language” and verify automatic time and time-zone settings. You can also query the synchronization status from a terminal with the required permissions:

w32tm /query /status
w32tm /resync

If Windows reports that the time service is not running, check the Windows Time service in Service Management first. Devices joined to a domain may be managed by an organization’s time server, so do not change the synchronization source casually.

Checking the time on macOS and Linux

On macOS, enable automatic time settings under “System Settings — General — Date & Time.” On Linux distributions using systemd, view the current time status with:

timedatectl status
sudo timedatectl set-ntp true

Applications in containers or virtual machines usually inherit the host’s clock. If only the virtual machine reports the error, check both the host and guest systems and confirm that time synchronization resumed after restoring a snapshot.

Verify the certificate chain seen by the browser

A certificate chain usually consists of the website certificate, intermediate certificates, and a trusted root certificate. The browser checks whether the requested domain appears in the certificate’s Subject Alternative Name, whether the certificate is within its validity period, whether the signature chain leads to a root certificate trusted by the device, and whether the certificate is suitable for server authentication. Do not rely only on the error-page title; open the certificate viewer and record the specific fields.

First, inspect the website certificate’s “Issued to” field or Subject Alternative Names and confirm that the current domain is included. Then check the “Issuer” and compare it with the result after disabling Clash. If the certificate subject, serial information, or issuer differs substantially between the two states, a middle layer is terminating and re-establishing TLS somewhere along the path. This may come from corporate compliance inspection, parental controls, HTTPS scanning by security software, a debugging proxy, or an upstream proxy service configured in the subscription.

If the certificate is always identical but one browser still reports that it is not trusted, compare the results across browsers. Some browsers primarily use the system certificate store, while others may maintain a separate certificate database. Incomplete system updates, an outdated root-certificate list, or corrupted browser settings can cause the same certificate to be judged differently by different programs.

Inspecting the handshake from the command line

Command-line tools can help distinguish browser configuration issues from system network problems. The requests below test the default connection and a connection through the local HTTP proxy port; adjust the port to match the client’s actual configuration:

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

Compare the certificate subject, issuer, validity period, and final error in the output. If the direct connection succeeds but the explicit proxy connection fails, continue by checking the node selected by Clash, the proxy group, and the upstream path. If both fail, system time, the certificate store, DNS, or the current network is more likely to be responsible. When testing a real failing domain, avoid exposing complete URLs containing account details, tokens, or query parameters in public logs.

Trace the Clash proxy chain and rule routing

Clash rule mode selects a proxy group, specific node, or DIRECT according to the order of rules in the configuration file. When a browser loads a page, the main domain, static assets, login endpoints, and content-delivery domains may match different rules. If the main page uses a proxy while an authentication endpoint connects directly to a restricted or redirected address, the browser may show a certificate error, a login loop, or handshake failures for only some resources.

Open the client’s connection records and core logs, locate the target domain near the time of the error, and confirm the matched rule, egress policy, and node. Clash Meta (mihomo) configurations can usually be inspected through the dashboard’s live connections. In different graphical clients, the relevant sections may be called “Connections,” “Logs,” “Rules,” or “Proxies.” The goal is not to keep switching global mode, but to determine which path the specific domain actually took.

Change one variable at a time

Keep the network unchanged, temporarily route the failing domain through DIRECT, and test again in the browser.
If the direct connection works, route the domain through another known-good node and check whether the certificate returns to normal.
If every node fails, check whether the subscription configures a shared chained proxy, external controller, or additional upstream.
If only one node fails, inspect its server address, port, transport parameters, TLS Server Name, and system time.
Restore rule mode after testing so a global policy does not hide the original rule-order problem.

The node protocol itself may use TLS to connect to the proxy server. That certificate is different from the certificate shown when the browser connects to a website. Messages such as “certificate verify failed,” “x509,” or “hostname mismatch” in node logs usually mean that the client failed to validate the proxy server’s certificate. A certificate warning in the browser points to the destination website connection. Separating these layers prevents a node-server certificate issue from being mistaken for a website certificate problem.

If a node configuration uses a domain name as the server address, the TLS Server Name should usually match a name covered by the server certificate. Changing it arbitrarily to an IP address, entering a different domain, or encountering a replacement of the upstream server certificate can cause the node handshake to fail. Use the valid configuration provided by the service operator, rather than keeping the connection alive by disabling node certificate validation.

System proxy vs. TUN mode

The system proxy mainly affects programs that follow the operating system’s proxy settings. TUN mode uses a virtual network adapter to capture a broader range of IP traffic and works with routing and DNS to handle applications that do not read system proxy settings. If many programs begin failing only after switching to TUN, common causes include conflicting DNS interception, another VPN changing routes, security software filtering the virtual adapter, or LAN authentication traffic being captured.

TUN mode does not automatically decrypt HTTPS just because it covers more traffic. If certificate name mismatches occur only with TUN enabled, temporarily disable TUN while keeping the system proxy enabled for comparison, then check fake-ip, the DNS listener, route exclusions, and other VPNs. Change one option at a time to determine whether the difference comes from routing, resolution, or the upstream node.

Identify DNS anomalies, captive portals, and network interception

A certificate name mismatch often means that the browser connected to the wrong server. Public Wi-Fi, hotels, and campus networks may require web-based authentication first. When a device connects for the first time, the gateway redirects ordinary requests to a login page. If HTTPS requests are intercepted too, the portal cannot provide a valid certificate for the requested domain, so the browser shows a certificate warning. Disable the proxy, open the operating system’s network-detection page or an ordinary HTTP page to complete authentication, then enable Clash again.

An incorrect DNS response can produce the same symptoms. With Clash disabled or enabled, DNS resolution may be handled by the system DNS, the client’s DNS module, a remote resolver, or fake-ip. If a domain fails in only one state, query the results separately and compare them with results from a trusted network. Large websites may use regional addresses, so different IPs do not necessarily indicate a problem; the key is whether the address ownership, certificate domain, and access result make sense.

nslookup example.com
dig example.com A
dig example.com AAAA

Security filtering on a home router, unusual redirects in an ISP network, TLS inspection at a corporate gateway, and a local debugging proxy can all change the connection path. The most useful cross-check is to connect the same device temporarily to another trusted network while leaving the Clash configuration unchanged. If access returns immediately, inspect the original router’s DNS, access controls, firmware settings, and network-authentication status. If every network fails, return to the local certificate store, client configuration, and security software.

Local filtering software and enterprise certificates

Some enterprise environments inspect HTTPS traffic using a managed root certificate. On organization-managed devices, this certificate is typically deployed by administrators, and the browser displays the organization’s designated issuer. An expired certificate, incomplete deployment, or a browser using a separate certificate store can cause trust errors. Record the subject, issuer, and validity period, then ask the network administrator to verify them; do not delete an organization certificate yourself.

If a personal device has had a packet-capture debugger, traffic-analysis tool, or security program with HTTPS scanning installed, check whether it is still running. Closing its interface does not necessarily stop its background service or local proxy. Verify the system proxy settings, process list, and certificate manager. After confirming the software’s source and purpose, remove its network components through the software’s official uninstall process.

Recover step by step and verify the result

Troubleshoot certificate failures by starting with changes that have the smallest impact and are easiest to undo. Resetting all network settings or deleting every certificate can damage the existing environment and destroy useful evidence. The sequence below suits most HTTPS errors that appear after enabling Clash.

Record the error: Save the browser error code, failing domain, certificate subject, issuer, validity period, and time of occurrence.
Correct the clock: Confirm the date, time zone, and automatic synchronization status, then restart the browser.
Compare modes: Test with Clash disabled, with only the system proxy, with only TUN, and with the original mode, recording each result.
Review connection logs: Confirm the matched rule, proxy group, node, and DNS resolution path for the target domain.
Replace one egress: Switch nodes without changing anything else and determine whether the problem follows the node.
Try a trusted network: Rule out effects from the router, public-network authentication, and gateway inspection devices.
Check intermediary software: Review other VPNs, local debugging proxies, security filters, and enterprise management policies.
Restore the configuration: If DNS, TUN, or rules were recently changed, revert each item using the previously saved configuration.

When to contact the website or service provider

If the same website shows the same expired certificate or incomplete chain on multiple devices and networks, both directly and through a proxy, the problem may be on the website’s server. Wait for site maintenance or contact its administrator. If the error follows only one proxy node and the node log clearly shows an invalid server-certificate name or validity period, report the time, node name, and a log summary to the configuration provider.

There is no need to submit the full subscription URL, authentication keys, or account information. Provide the client core version, operating system, connection mode, time of the error, target domain, matched rule, and a redacted log excerpt. Clearly distinguishing a “node TLS handshake failure” from a “browser certificate warning when visiting a website” can significantly shorten diagnosis.

Configuration to review after recovery

Once the error disappears, do not immediately assume it was random. Re-enable the original rule mode and test commonly used websites, software updates, login endpoints, and applications that do not follow the system proxy. If TUN or the DNS module was temporarily disabled, restore each one separately and watch the logs. If a custom rule sends an authentication domain through a different egress from the main site, place the related domains in the same policy group and document the rule order so it can be reviewed after subscription updates.

For devices that frequently switch between corporate networks, home networks, and public Wi-Fi, keep a baseline configuration for comparison: a stable subscription, explicit DNS settings, and fewer custom rules. When a problem occurs, reproduce it with the baseline first, then add TUN, scripts, or custom rules one at a time. This minimal test makes the failing layer easier to identify than repeatedly reinstalling the client.