HTTPS Certificate Errors When Using a Proxy on Mac: Causes and Fixes

1. Save the Error Details—Don’t Bypass the Warning

After launching a Clash client, you may see a browser warning such as “Your connection is not private.” This means the browser couldn’t verify the website’s identity. It doesn’t necessarily mean the node timed out or your subscription stopped working. The connection may have reached a server, but its certificate, certificate chain, or your Mac’s trust settings failed validation.

Before troubleshooting, don’t enter passwords, payment details, or verification codes on the affected page. Note the full hostname in the address bar, the browser error code, the certificate issuer, and its validity dates. If you take a screenshot to ask for help, hide account details, subscription URLs, and query parameters containing tokens.

2. What a Clash Proxy Does During the HTTPS Handshake

A Standard Proxy Doesn’t Replace the Website’s Certificate

For example, when a browser accesses an HTTPS site through a local HTTP proxy, it first sends CONNECT example.com:443 to the proxy. The proxy opens a forwarding tunnel, then the browser and website perform the TLS handshake. The browser verifies the website’s certificate. A local listening port such as 7890 does not mean HTTPS traffic becomes plaintext.

SOCKS proxies and TUN mode handle traffic at different points, but neither inherently decrypts HTTPS. Standard forwarding in Clash and Clash Meta (now called mihomo) does not require installing a root certificate to decrypt web traffic. Traffic sniffing in a configuration is also not the same as decrypting HTTPS content: reading visible handshake metadata and issuing a substitute certificate are two different things.

Node TLS and Website TLS Are Separate Connections

Some node protocols also use TLS. In that case, one handshake takes place between the client and the node server, and another between the browser and the website. If logs show that certificate verification failed on the node connection, the usual result is a failed proxy connection, timeout, or tunnel error—not necessarily a browser warning about the website’s certificate.

In configurations that support it, skip-cert-verify controls certificate verification for the relevant outbound connection. It won’t fix a website’s certificate chain or make the browser trust that site. Don’t set it to true just to address a browser warning. Instead, check that the node address, server certificate, and TLS server name are configured correctly by your provider.

3. Check the System Clock, Then Change One Variable at a Time

Check the Date and Time in macOS

On macOS Ventura 13 and later, open System Settings → General → Date & Time. Check that Set time and date automatically is enabled, and verify the current date, year, and time zone. On older macOS versions, check System Preferences → Date & Time. Pay particular attention to the year after restoring an old system backup or being offline for an extended period.

Certificate validity is checked against timestamps. If your Mac’s clock is wrong, a valid website may appear to have a certificate that is not yet valid or has expired. Changing the time zone alone usually won’t correct an inaccurate system clock; use the actual time after automatic synchronization. Once corrected, quit and reopen the browser, then visit the same hostname again.

Compare Four Results for the Same URL

1. Current node: Record the browser error and certificate issuer, along with the rule and outbound policy shown in the client’s connection list.
2. Another node: Switch only the node in the policy group. Don’t change DNS, rules, or browser settings at the same time.
3. Direct connection: Temporarily turn off the system proxy and TUN, and check whether browser extensions or separate proxy settings are still routing traffic.
4. Another network: If possible, try the same URL over a personal hotspot to check whether the current Wi-Fi, router, or managed network is involved.

A failed direct-connection test doesn’t necessarily mean the website has a certificate problem; the current network may simply be unable to reach it. A comparison is useful only when you can inspect the certificate, error code, or a successfully loaded page. Keep the URL unchanged, and check whether it redirects to a different subdomain.

4. Check for HTTPS Interception and Unfamiliar Root Certificates

Corporate HTTPS inspection, debugging tools, and some security software may terminate TLS between your browser and a website, then present the browser with a newly issued certificate. This requires the device to trust the relevant root certificate. A root certificate that wasn’t deployed correctly, has expired, or was left behind after software removal can trigger an “untrusted” warning.

• Check the issuer: In the browser’s warning details or certificate viewer, note the certificate issuer. The same unfamiliar organization appearing on multiple unrelated sites is a clue worth investigating.
• Check the certificate store: Open Applications → Utilities → Keychain Access, then inspect the certificates in the Login and System keychains. Don’t bulk-delete system root certificates.
• Check debugging tools: If you’ve installed an HTTPS debugging proxy, turn off its HTTPS decryption and system-proxy routing, then test again. This helps rule out conflicts between two local proxies.
• Check whether the Mac is managed: If your Mac is managed by your organization, certificates may have been deployed through device management. Ask your administrator to confirm their purpose, validity, and deployment status. Don’t change your organization’s trust settings yourself.

A change in issuer alone doesn’t prove an attack. Large websites may change certificate authorities, and different CDN edge servers may present different certificates. Consider hostname coverage, validity dates, the trust chain, and results from multiple connection paths. If a personal device suddenly prompts you to install an unknown root certificate to “fix” a proxy, stop and verify where it came from.

5. Distinguish Node Issues, DNS Problems, and Website Misconfiguration

If Only One Node Fails, Stop Using It First

If the same hostname works through other nodes but one node consistently returns a certificate for an unrelated domain, the issue may involve that node’s DNS, network interference, or server-side routing. Stop using it for sensitive sites and send your provider the time of the error, target hostname, error code, and certificate issuer. One error alone isn’t enough to conclude that the node operator is hijacking traffic.

If DNS is rewritten, a connection may reach the wrong server; normal certificate validation should prevent that server from impersonating the original website. mihomo’s Fake-IP mode maps a domain to a synthetic address locally, then lets the core handle the connection—seeing a synthetic address doesn’t mean DNS has been poisoned. Check the domain identified in the connection details, the matched rule, and the actual outbound route.

If Every Route Fails for One Site, Check Its Certificate

If the same website shows a similar error through different nodes, a direct connection, and other devices, consider an expired certificate, incomplete hostname coverage, or a missing intermediate certificate. For example, a wildcard certificate for *.example.com will typically match www.example.com, but it won’t match a.b.example.com on its own, and it doesn’t automatically cover the bare domain example.com.

If a server omits an intermediate certificate, browsers may behave differently depending on their caches or ability to retrieve missing certificates. So “it works in Safari but not in another browser” doesn’t rule out a server configuration problem. Record the certificate chain and contact the site administrator instead of changing your Mac’s trust settings.

If It Happens Only on Public Wi-Fi, Complete Network Sign-In First

Hotel and airport networks may require you to sign in through a captive portal. If the portal redirects an HTTPS request to its login page, the hostname won’t match the certificate. Complete sign-in using the macOS network login prompt; don’t enter your website password on a certificate warning page. If the problem persists afterward, try a personal hotspot.

6. Compare Direct and Local Proxy Connections with curl

Terminal tests can provide clues independent of browser caches and extensions, but they don’t replace browser results. First, check the HTTP or mixed-port listener in your client settings. The 127.0.0.1:7890 address below is just an example, not a default for every client. Replace the example domain with the hostname that’s failing, and keep https://.

# Record the curl version and TLS backend
curl --version

# Bypass curl's proxy selection; traffic may still be routed if TUN is enabled
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# Explicitly use the local HTTP / mixed proxy port
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '' \
  --proxy http://127.0.0.1:7890 https://example.com/

• Set up a true direct-connection test: In addition to using --noproxy '*', turn off TUN and make sure no other VPN or network extension is routing traffic. This option bypasses only curl’s own proxy selection.
• Tell the tunnel from the website: 200 Connection established in the output usually means the proxy accepted the CONNECT request. It doesn’t mean the target website’s certificate has been verified.
• Identify the error type: curl: (60) usually means the peer’s certificate couldn’t be verified; curl: (7) usually means the connection failed. First determine whether the local proxy isn’t listening or website TLS verification failed.
• Account for differences in trusted certificate sources: The curl bundled with macOS and versions installed from other sources may use different TLS backends and CA stores. If one works and the other fails, check their versions and certificate trust sources.

These commands set a 10-second connection timeout and a 20-second total time limit to avoid tests hanging indefinitely; they are not performance benchmarks. -I sends a HEAD request. Some websites return 405, but if TLS verification has already succeeded, an unsupported HTTP method is a separate issue from a certificate error.

7. Fix the Cause, Then Make Sure It’s Not Hidden

1. Incorrect system time: Re-enable automatic time setting, reopen the browser, and confirm the original hostname now verifies successfully.
2. Corporate HTTPS inspection issue: Ask an administrator to fix certificate deployment or check the gateway. Don’t install an unknown root certificate from a chat attachment.
3. Problem with one node: Stop using it, save the evidence, and contact your provider. Retest using another trusted connection.
4. Website certificate problem: Wait for the site to renew its certificate, complete the intermediate chain, or fix its hostname configuration. Reinstalling the local client usually won’t help.
5. Conflict with local software: Follow the software’s documentation to turn off HTTPS decryption and proxy routing. Change one setting at a time, then repeat the same test.

Finally, restore the rule mode, system proxy, or TUN settings you actually need. Retest the affected site and two other websites that use HTTPS. Make sure the address bar hasn’t redirected unexpectedly, the certificate is valid, and the client’s connection list shows the expected outbound route. If switching browsers makes the warning disappear, check for differences in their trust sources or extensions rather than assuming the problem is fixed.

For client installation and initial setup, see the Quick Start Guide. To check proxy protocols, rules, or DNS settings, consult the Protocol Guide. When troubleshooting certificate errors, focus on the system clock, hostname, certificate chain, and connection path—not repeatedly updating subscriptions or randomly changing ports.