客户端指南

Clash 节点里的 skip-cert-verify 会关闭网站 HTTPS 吗？

节点配置中的 skip-cert-verify 只跳过 Mihomo 对 TLS 代理节点的证书验证，不会自动关闭目标网站 HTTPS，但会削弱节点身份校验。

发布于 2026/8/16 · 更新于 2026/8/16 · 3 项可核验来源

先看重点不会直接关闭目标网站的 HTTPS。写在 proxies 节点里的 skip-cert-verify: true，跳过的是 Mihomo 到 TLS 代理节点这一跳的证书验证；浏览器或 App 与目标网站的内层 HTTPS 通常仍会自行校验。它也不同于订阅更新时的“允许无效证书”和安装根证书。网页小锁仍在不代表外层安全，普通订阅应要求服务商修正证书或 servername。

导入订阅后，节点配置里多出一行 skip-cert-verify: true。节点能连，网页仍有 HTTPS 小锁，很容易让人觉得这行配置没有实际影响。

它不会直接关闭目标网站的 HTTPS，但会绕过代理节点这一跳的证书验证。 两层 TLS 可以同时存在，网页小锁只能说明网站这一层通过了检查。

先确认它出现在哪一层

相似的“跳过证书验证”字样可能出现在三个地方，影响并不相同：

出现位置	影响的验证边界
`proxies` 节点里的 `skip-cert-verify`	Mihomo 连接 TLS 代理节点时，对节点证书的验证
订阅更新界面的“允许无效证书”	客户端下载订阅文件时，对订阅服务器证书的验证
浏览器“继续访问”或系统安装根证书	目标网站或整台设备的 HTTPS 信任边界

本文只讨论第一种。若错误发生在订阅更新阶段，应看Clash Verge Rev 订阅更新报错排查；陌生根证书则是另一种权限，不能混为同一个开关。

这行配置只管哪一段连接

在 Mihomo 的 proxies 配置里，相关字段通常出现在启用了 TLS 的节点旁边：

tls: true
servername: node.example
skip-cert-verify: true

Mihomo 官方文档把它定义为“跳过证书验证”，并说明它只适用于使用 TLS 的协议。这里验证的是客户端到代理节点这一跳：节点给出的证书链是否可信，证书身份是否与预期服务器名称相符。

它不会给操作系统安装根证书，也不等于关闭浏览器对目标网站的 HTTPS 检查。访问 HTTPS 网站时，网站自身的 TLS 通常仍在代理隧道内进行；外层节点连接和内层网站连接是两道不同边界。普通代理为何不该要求安装根证书，可对照代理客户端要求安装根证书正常吗。

为什么改成 true 以后马上能连

正常验证会检查证书链和服务器名称。Go 的 TLS 标准库文档说明了跳过默认校验的一般后果：客户端可能接受任意服务器证书和证书中的任意主机名，除非程序另外实现了自定义校验。RFC 9525 也要求客户端把预期的服务身份与证书呈现的身份进行匹配。

因此，true 后连接恢复，能说明的只有“原来的验证不再拦截这次连接”。它不能证明证书已续期、域名已经匹配，或中间路径值得信任。

常见根因仍可能是证书过期、证书链不完整、servername 填错、系统时间不准，或者连接到了非预期服务器。报错属于握手超时还是证书校验失败，可先看TLS handshake timeout 和证书错误的区别；日期异常则单独参考系统时间导致的证书错误。

普通订阅可以这样判断

看到的情况	更稳妥的判断
保持证书验证时节点也能正常连接	没有理由额外跳过验证
只有打开 `skip-cert-verify` 才能连接	证书或服务器名称问题仍未解决，应让服务商说明原始错误
对方只说“这样更快”或“兼容性更好”	解释不足；证书验证不是测速选项
配置每次更新都重新带回 `true`	不要反复盲改订阅，要求服务商给出可验证的长期方案
自己维护的测试节点使用自签名证书	可以设计私有信任或证书锁定，但必须独立核对身份

不要靠猜测修改 servername。Mihomo 会用它参与节点 TLS 连接与证书身份判断，填成一个“看起来正常”的域名并不会让错误配置变安全。普通用户需要的是服务商给出的正确名称和有效证书，不是一串试到能连为止的值。

自签名证书也需要身份依据

自签名证书不必然恶意，但它没有公共 CA 信任链替你证明服务端身份。若节点由你自己维护，可以通过受控的私有 CA，或核对过的证书指纹建立信任。Mihomo 文档支持证书指纹校验，并说明叶子证书指纹会用于比对服务端发来的证书。

关键在“从哪里核对”。如果节点地址、skip-cert-verify 和指纹全部来自同一份未经确认的订阅，替换订阅的人也可以一起替换这些值，指纹就没有提供独立证据。指纹应从另一个可信渠道取得；证书轮换后也要重新核对，不能复制群里一段配置就算完成验证。

网站还显示小锁，不代表外层没有风险

目标网站的 HTTPS 仍然有效时，代理节点通常不能直接读到网页密码和正文；这也是打开 skip-cert-verify 后浏览器小锁仍可能正常显示的原因。但这不该被扩大成“节点身份无所谓”。一旦节点 TLS 的身份校验被绕过，客户端更难发现有人正在冒充预期代理服务器。

实际暴露范围取决于代理协议、连接方式，以及目标流量是否还有端到端加密。既不能声称开关一开所有 HTTPS 都会被解密，也不能因为网页有小锁就忽略外层验证。两层可见信息的边界见机场能看到 HTTPS 的哪些内容。

找服务商时，问清三件事就够了

关闭跳过验证后，完整的证书错误是什么；
这个节点应匹配哪个 servername，证书链和有效期是否正常；
若确实使用自签名证书，证书指纹从哪个独立渠道核对，轮换时怎样通知。

发送日志时不要附上完整订阅 URL、UUID、密码或未打码配置。保留协议类型、节点域名、时间和证书错误即可；需要公开求助时，可按Clash 日志脱敏清单处理。

如果对方唯一能给出的理由仍是“设成 true 就能用”，那只是绕过了报错，没有回答客户端如何确认节点身份。

资料来源

以下来源于 2026/8/16 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题