先记录错误代码，再区分故障范围
开启 FlClash 后出现“您的连接不是私密连接”，说明浏览器在验证 HTTPS 身份时遇到问题。排查起点是错误代码、目标域名和证书详情，而不是反复刷新页面。遇到登录、支付或邮箱页面时，先停止提交密码与验证码，保留错误页面信息。
展开浏览器错误页的“高级”说明，记录完整错误代码；若页面提供查看证书入口，再记录证书的颁发者、有效期和主题备用名称。不同浏览器的入口位置会变化，优先使用错误页自身提供的证书信息。
| 常见错误 | 验证失败的方向 | 优先检查 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | 当前时间不在证书有效期内 | 设备日期、时间同步、站点证书到期时间 |
NET::ERR_CERT_COMMON_NAME_INVALID | 证书覆盖的域名与访问域名不匹配 | 地址栏拼写、证书 SAN、DNS 与重定向 |
NET::ERR_CERT_AUTHORITY_INVALID | 证书链无法连接到受信任的根 | 颁发者、站点证书链、HTTPS 检查软件 |
SSL_ERROR_BAD_CERT_DOMAIN | Firefox 检测到域名不匹配 | 目标主机与证书覆盖范围 |
接着判断范围：只有一个站点报错，还是多个互不相关的 HTTPS 站点同时报错？只有一个节点出错，还是关闭代理后也出错？这些差异比“网络能否打开”更能定位问题。连接超时、连接重置和证书错误属于不同阶段，不能套用同一种处理方式。
HTTPS 握手与代理：两层证书需要分开看
浏览器访问 HTTPS 网站时，会验证目标网站证书的域名、有效期和信任链。通过普通 HTTP 代理访问 HTTPS 时，浏览器通常先用 CONNECT 建立隧道，再与网站进行 TLS 握手；SOCKS 代理和 TUN 接管也可以转发这段加密流量。常规转发本身不要求浏览器安装专用根证书。
如果节点协议本身使用 TLS，还会多出“客户端到代理节点”的验证。此时 mihomo 日志中的 x509: certificate has expired or is not yet valid 或 certificate signed by unknown authority，可能指向节点证书；浏览器错误页展示的证书则通常属于浏览器正在访问的站点。这两层要分别定位。
- 浏览器直接展示证书警告：先看目标网站域名、颁发者、系统时间与本机信任库。
- 客户端日志报告节点 TLS 失败：核对节点服务器名称、订阅参数和节点证书状态，联系提供方处理。
- 页面显示代理连接失败或一直超时：先检查本地监听端口、节点连通性与路由，不要直接归因于网站证书。
系统时间错误：先修正日期与自动同步
证书有明确的生效和到期时间。设备日期落在有效期之外，即使网站配置正常也会失败。双系统切换、长期关机或主板电池异常，都可能使系统时间偏移。先与可信的时间来源对照，检查年份、日期和分钟，再确认时区。
- Windows 11：打开「设置」→「时间和语言」→「日期和时间」，启用“自动设置时间”，在“其他设置”中选择“立即同步”。
- macOS：打开「系统设置」→「通用」→「日期与时间」，检查自动设置时间与日期；修改时可能需要管理员授权。
- Android：在系统设置中搜索“日期和时间”，启用自动时间与自动时区。厂商系统的菜单层级可能不同。
- 完成同步后，关闭发生错误的标签页，重新访问同一域名，再检查证书有效期。
时区影响显示方式，证书有效性实际按时间点判断。仅仅把时区名称改正确，却仍保留错误的系统时钟，问题可能继续存在。若时间正确且只有一个站点提示过期，应由站点维护者更新证书；切换代理节点不能让过期证书重新有效。
中间人证书：检查颁发者与本机 HTTPS 检查
企业网关、部分安全软件和调试代理可能提供 HTTPS 解密检查。它们会向浏览器出示重新签发的证书，再代表浏览器连接目标网站。如果相应根证书未受信任、已经过期，或软件配置残留，就可能出现颁发机构不受信任的提示。
用同一域名做三项对照
- 比较出错设备与另一台正常设备上的证书颁发者。证书可能因 CDN 或更新而不同，但出现公司网关、安全软件或调试工具名称值得重点核查。
- 比较同一设备上的两个浏览器。浏览器使用信任库的方式可能不同，只有一个浏览器报错时，优先检查其证书设置、扩展和管理策略。
- 在获准的情况下，改用手机热点测试。若只有公司网络触发问题，应交由网络管理员确认检查策略和证书分发状态。
Windows 可运行 certmgr.msc 查看当前用户的证书存储，运行 certlm.msc 查看本地计算机的证书存储；重点核对“受信任的根证书颁发机构”，不要按陌生名称批量删除。macOS 可在“钥匙串访问”中检查相关证书及信任设置。受管理设备的证书应按组织流程处理。
如果之前安装过抓包调试工具，可退出工具并检查系统代理是否仍指向它。浏览器同时受扩展代理与系统代理影响时，可能进入不同链路。每次只调整一项，重新测试后记录结果，避免同时删除证书、重置浏览器和修改配置而失去判断依据。
域名不匹配：检查 DNS、认证门户与分流
DNS 异常可能把域名指向错误服务器，但并非每次解析异常都会表现为证书警告，也可能只是超时。域名不匹配时，先检查地址栏是否存在拼写错误，再查看证书的主题备用名称（SAN）是否覆盖当前主机名。证书覆盖 example.com，不代表必然覆盖其所有子域名。
公共网络先完成联网认证
酒店、机场或校园网络可能要求先经过认证门户。通过系统的“登录网络”通知进入认证页，确认所属网络后完成认证，再测试 HTTPS。不要在原本访问银行或邮箱的证书错误页中输入公共网络账号；认证门户与目标站点应分开识别。
系统 DNS 与代理 DNS 分开验证
Windows 可用下面的命令查看系统解析结果。此命令只展示相应解析路径，不一定等同于浏览器的安全 DNS 或 mihomo 的 DNS 结果。
nslookup example.com
ipconfig /flushdns第二条命令用于清理 Windows 系统 DNS 缓存，不会自动清理浏览器、上游解析器和 mihomo 内部缓存。若配置使用 Fake-IP，观察到映射地址并不等同于 DNS 污染；mihomo 常见的 Fake-IP 地址池位于 198.18.0.0/16，实际应以当前配置为准。
在 FlClash 的连接记录中搜索出错域名，核对它命中的规则与实际出站策略。规则模式按配置选择直连或代理；全局模式改变出站选择，但不会修复系统时间或信任库。若浏览器启用了安全 DNS，也应记录其状态，避免只改系统 DNS 就认定所有解析路径已改变。
节点与 TUN 排查：一次只改变一个变量
“换节点后恢复”只能说明故障与该链路相关，还需要确认原节点是否存在错误解析、出口重定向或连接异常。正常的端到端 HTTPS 连接仍应由浏览器验证网站身份；出现陌生证书时，保留证书信息并暂停使用该异常链路。
- 记录当前出站模式、选中节点、系统代理与 TUN 开关，以及出错域名和错误代码。
- 保持节点不变，先关闭 TUN，仅通过已确认的系统代理测试浏览器，确认请求是否仍经过客户端。
- 恢复原设置，只切换一个节点，再访问同一域名，比较错误代码和证书颁发者。
- 在网络允许直连且符合使用要求时，关闭系统代理与 TUN 后对照测试。浏览器扩展或命令行环境变量也可能继续指定代理，需要一并检查。
- 对照客户端日志的时间点，判断失败发生在节点 TLS 连接，还是网站访问阶段。
用明确端口测试 HTTP 代理
下面以本地 HTTP 或混合端口 7890 为例。先在当前客户端配置中确认实际端口，再替换命令中的端口号；该数值仅为示例，不代表所有 FlClash 配置的默认值。Windows 使用 curl.exe 可避免旧版 PowerShell 的命令别名差异，macOS 或 Linux 使用 curl。
curl.exe --noproxy "*" -Iv --connect-timeout 10 https://example.com/
curl.exe --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/第一条绕过 curl 的显式代理设置，第二条明确指定本地 HTTP 代理。两条命令都保留证书验证，连接超时设为 10 秒。TUN 开启时，第一条的流量仍可能被接管，因此不能单凭 --noproxy 就把它视为真正直连。SOCKS 专用端口也不能直接填入 HTTP 代理地址。
curl 与浏览器可能使用不同的证书后端和信任库，因此命令成功只是一项对照结果，不代表浏览器问题已经解决。分享详细输出前，删除代理认证信息、Cookie、订阅地址及其他敏感内容。
恢复标准：验证证书，再恢复日常配置
完成修改后，重新访问最初出错的域名，再访问两个互不相关的常用 HTTPS 站点。检查页面是否正常加载、错误代码是否消失，以及证书有效期和域名是否匹配。随后恢复日常使用的规则模式、系统代理或 TUN 设置，再重复一次测试。
- 仅一个网站持续失败：向站点维护者反馈域名、错误代码、证书有效期和测试时间。
- 仅一个节点持续失败：向订阅提供方反馈节点名称、发生时间与脱敏日志，不公开订阅链接。
- 仅公司网络或受管理设备失败：联系管理员检查根证书分发、网关时间与 HTTPS 检查策略。
- 所有网络均失败：继续检查设备时间、系统更新、浏览器信任库和本机安全软件。
证书错误的处理目标是恢复可验证的连接，而不是隐藏警告。需要重新核对客户端接管方式时，可查看快速上手教程；订阅与连接基础问题可参考疑难解答。