HTTPS Certificate Error After Enabling Clash: Causes and Fixes

First determine whether Clash is actually causing the certificate error

An HTTPS certificate error does not necessarily mean the Clash client is broken. When you visit an HTTPS website, the browser checks the certificate’s domain, validity period, issuing authority, and certificate chain. Clash typically only forwards encrypted traffic and cannot read an established TLS session. As long as the destination, system time, and certificate chain are correct, enabling rule-based proxying or TUN mode does not itself require you to install a website certificate.

Problems are more likely after the forwarding path changes: a proxy node may send the connection to the wrong server, DNS may return an abnormal address, a local HTTP proxy may try to decrypt the traffic, or an incorrect device clock may make the validity check fail. Enabling Clash may happen to trigger one of these path changes, so the events appear related in time. During troubleshooting, however, distinguish between the client, configuration, node, and destination website.

Start with a simple on/off comparison

1. Record the full domain of the affected site, such as accounts.example.com, rather than only the homepage name.
2. Capture the error code, certificate issuer, and validity period shown on the warning page. Safari may show “This Connection Is Not Private,” while Chromium-based browsers commonly display NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, or NET::ERR_CERT_AUTHORITY_INVALID.
3. Turn off Clash’s system proxy or VPN connection, fully quit and reopen the browser, then visit the same HTTPS address again.
4. Enable Clash again and temporarily set the domain to DIRECT. If the direct connection works but the proxy group reports an error, focus on the current node and upstream route.
5. Test separately over Wi-Fi and cellular data. If the error occurs only on one Wi-Fi network, check the router, public-network sign-in page, and manual proxy settings first.

Node hijacking or an incorrect certificate from upstream

When rules send a domain through a proxy node, that node connects to the destination server on behalf of the device. If the node’s exit is taken over by a transparent proxy, malicious gateway, or faulty upstream service, the browser may receive a certificate for another domain or one issued by an authority the device does not trust. These problems usually occur only with a particular node or route group.

Typical signs

• The same site works with DIRECT but shows a domain mismatch after switching to a specific proxy node.
• The certificate’s “Issued to” field has no relation to the domain in the address bar—for example, an account domain returns a router management page certificate or one for an unfamiliar domain.
• The site works after switching to another regional node in the same subscription, while repeated tests with the original node still fail.
• An HTTP site redirects to an ad page, sign-in page, or unfamiliar search page, while HTTPS sites simultaneously show certificate errors.

Clash’s global mode is useful for comparing nodes because all matching traffic enters the current proxy group. Restore the original rule mode after testing. If only one node is affected, there is no need to delete the entire subscription; exclude that node from the proxy group first, then update the subscription to see whether the provider changes the route.

Check these three certificate fields

1. Subject Alternative Name: It should include the complete domain you are visiting. A wildcard such as *.example.com generally covers only one subdomain level.
2. Issuer: Check whether the issuing authority remains consistent. If it suddenly changes from a public CA to a company gateway, router device, or unfamiliar name, treat the connection with caution.
3. Validity: Confirm that the current time falls between the “not before” and “not after” dates. An expired certificate may also indicate maintenance problems on the website itself.

On macOS, you can use the built-in command-line tools to inspect the remote handshake. Replace example.com below with the domain that reports the error; port 443 is the standard HTTPS port:

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -Iv https://example.com/

-servername sends SNI. Without it, the same server may return its default certificate and lead to a false conclusion. Certificate details in the command output can help compare direct and proxied tests, but a displayed “successful handshake” does not prove that the website content is safe. You still need to verify the domain and certificate chain.

Incorrect system time can make certificate validity checks fail

Certificates contain explicit not-before and expiration times. If an iPhone clock is several days slow, a new certificate may appear to be “not yet valid”; if it is several months fast, a valid certificate may appear “expired.” This type of failure often affects a range of HTTPS services, app sign-ins, and system accounts at the same time rather than just one website.

Check the time on iPhone and iPad

Open “Settings” → “General” → “Date & Time” and turn on “Set Automatically.” Then confirm that the time zone matches your location. If the switch is dimmed, it may be controlled by Screen Time restrictions, carrier settings, or device-management policies; address the applicable restriction first.

• When the clock is off by more than five minutes, some login tokens and one-time verification codes may fail at the same time.
• After correcting the time, close the affected Safari tabs and reopen them so they do not continue reusing old connections.
• If the device has just resumed after being powered off for an extended period, connect it to a stable network and wait for automatic time synchronization to finish.
• For a company-managed device, contact the administrator instead of removing a management profile installed by your organization.

Pay attention to the dates shown in the certificate error. If the browser says the certificate has just expired while the system date is accurate, and the same result appears with direct connections, different nodes, and different networks, the problem is more likely on the website’s server. Changing Clash settings cannot fix it; the site operator must renew the certificate.

DNS poisoning can send a domain to the wrong server

Before an HTTPS connection begins, the device resolves the domain name to an IP address. If DNS returns the wrong address, the TLS request reaches another server, which may naturally return a certificate that does not match. The browser will commonly report that the certificate is invalid for the current domain rather than simply timing out.

In Clash or mihomo configurations, DNS behavior may come from nameserver, fallback, nameserver-policy, Fake-IP mappings, and rules using DOMAIN or DOMAIN-SUFFIX. TUN mode may also take over system DNS requests. Change one variable at a time during troubleshooting; otherwise you will not know which setting affected the result.

Check DNS by changing as few variables as possible

1. Update the subscription and configuration first, and confirm that the YAML loads successfully without indentation or field errors.
2. Temporarily add the affected domain to a direct-connection rule and confirm that the rule appears before MATCH.
3. Clear the client’s DNS cache. If the client has no separate option, disconnect the system VPN for about 10 seconds and reconnect it.
4. Toggle Airplane Mode off and on to refresh the cellular connection and DNS state.
5. Retest on another Wi-Fi or cellular network to distinguish local-router DNS problems from Clash’s built-in DNS.

A temporary rule can look like the example below. Rules are matched from top to bottom, so specific domains should appear before broader rules:

rules:
  - DOMAIN,accounts.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

If the direct rule still uses Clash’s DNS module, the test only shows that the egress path changed; it does not fully rule out DNS. A stricter comparison should test system DNS and configured DNS separately. Save the original configuration before making changes and restore it afterward so a temporary rule does not permanently disrupt existing traffic routing.

Fake-IP is not certificate forgery

Fake-IP mode returns reserved addresses to local applications, then the core forwards connections according to the domain mapping. An application may see an address in a range such as 198.18.0.0/15, but the TLS handshake should still use the original domain. Seeing a Fake-IP address alone does not mean the certificate was replaced. The real concerns are a lost domain mapping, DNS requests bypassing the core, or an application that is incompatible with Fake-IP and reaches the wrong destination.

If only LAN devices, game consoles, or a few incompatible apps are affected, add domain-specific Fake-IP filters instead of disabling the entire DNS system. The exact fields depend on the Clash Meta or mihomo configuration version; after editing, verify that the configuration passes validation before starting TUN.

How HTTP proxies, traffic-inspection tools, and installed certificates affect HTTPS

When ordinary Clash forwarding handles HTTPS, it normally provides only a connection tunnel and does not issue website certificates. A device sees a certificate reissued by a local or gateway CA only when a traffic-inspection tool, debugger, parental-control app, enterprise gateway, or content filter actively decrypts TLS. If that CA is not trusted by the system, every decrypted website may show an “issuer not trusted” error.

Check the Wi-Fi manual proxy

On iPhone, open “Settings” → “Wi-Fi” → the info button next to the current network → “Configure Proxy.” When using Clash through a system VPN or network extension, this should normally be set to “Off” unless you intentionally need a LAN proxy.

Common local HTTP or mixed-listener ports include 7890, while SOCKS commonly uses 7891, although configurations can change them. If the Wi-Fi proxy points to an unfamiliar LAN address such as 192.168.1.20:8080, record the setting, turn the proxy off, and test again. Do not treat 127.0.0.1 on one device as another computer; a loopback address always refers to the current device.

Check configuration profiles and certificate trust

1. Open “Settings” → “General” → “VPN & Device Management” and look for configuration profiles you do not recognize.
2. Open “Settings” → “General” → “About” → “Certificate Trust Settings” and review root certificates that have been enabled for full trust.
3. Do not install a CA supplied temporarily by an unknown webpage just to remove a warning, and do not enable full trust for an unfamiliar root certificate.
4. Company- or school-managed devices may legitimately deploy inspection certificates. Confirm the certificate’s name, purpose, and expiration with the network administrator first.

Deleting a Clash configuration usually does not remove profiles or root certificates installed by other tools. Conversely, deleting an enterprise certificate without checking can break company Wi-Fi, internal websites, and email. Identify the certificate’s source before deciding whether to disable an inspection tool, turn off the manual proxy, or ask an administrator to reinstall it.

Focused checks for Clash configuration and rules

A certificate error can also result from choosing the wrong egress through a rule. For example, a domain that should be direct may be sent to an unstable node by an overly broad DOMAIN-SUFFIX rule, or a subscription may have changed a policy-group name so the rule falls through to the final MATCH policy. Check the actual rule-hit record instead of relying only on the displayed mode name.

Confirm the mode and policy group

• Rule mode: Rules decide whether traffic is direct, proxied, or rejected, making this mode useful for tracing a specific domain match.
• Global mode: All traffic uses the current global node, making it useful for comparing nodes; restore the original mode after testing.
• Direct mode: Bypasses proxy nodes and helps determine whether the problem follows the proxy chain.

Open the client’s connection log and find the affected domain and its subdomains. Modern websites may contact separate login, static-resource, and API domains, so a direct connection to the main page does not mean every request is direct. Check the matched rule type, policy-group name, and final node.

Avoid mixing ports and proxy chains

Running a desktop traffic-inspection tool, browser proxy extension, and Clash at the same time can create multiple proxy layers. For example, a browser extension may point to 127.0.0.1:8080, while the inspection tool forwards to Clash at 127.0.0.1:7890. If any layer enables HTTPS decryption, it may change the certificate.

During troubleshooting, keep only one path active: disable browser proxy extensions, stop traffic-inspection tools, and let the system proxy or TUN connect directly to Clash. When restoring the setup, enable one component at a time and test the same domain after each change. This reveals which layer begins replacing certificates.

A low-risk-to-high-risk troubleshooting sequence

1. Save the error details: Record the domain, time, error code, certificate issuer, and current node.
2. Stop entering sensitive information: Until the cause is clear, do not sign in or submit payment details.
3. Correct the system time: Enable automatic setting under “Settings” → “General” → “Date & Time.”
4. Compare with Clash disabled: Quit the browser and test again to rule out reuse of an old connection.
5. Test direct mode and other nodes: Determine whether the error follows a particular proxy exit.
6. Change networks: Compare Wi-Fi and cellular data to identify router or public-network sign-in interference.
7. Check the rule match: Confirm the policy group and node actually used by the domain.
8. Check DNS: Clear the cache and review Fake-IP, nameserver, and domain policies.
9. Check the manual proxy: Review Wi-Fi “Configure Proxy” and browser proxy extensions.
10. Check root certificates: Confirm the source of configuration profiles and fully trusted certificates.

If the error occurs only with one node and the certificate domain is clearly wrong, stop using that node and send the subscription provider the time, target domain, and certificate issuer. If every network and device sees the exact same expired certificate on one website, wait for the site operator to fix it.

If many HTTPS websites still show errors after removing an unfamiliar proxy or disabling a problematic node, back up important data first, then consider resetting network settings. On iPhone, go to “Settings” → “General” → “Transfer or Reset iPhone” → “Reset” → “Reset Network Settings.” This clears saved Wi-Fi networks, VPNs, and some network parameters, so do it only after routine checks—not as the first step.

Frequently asked questions