看到“机场用了自签证书”“节点能被 MITM”的讨论，你可能最关心两件事：自己的节点还能不能用，账号密码会不会被别人看到。

先说结论：自签证书不等于不安全，关键是客户端有没有可靠地验证服务器身份；跳过节点证书验证会带来风险，但不等于 HTTPS 网页内容自动变成明文。 不必因为一张群聊截图立刻更换软件，也不要因为节点能连接，就忽略证书设置。

下面先交代 Surge 与 VLESS 争议的背景，再按配置检查自己的节点。涉及具体字段的说明以 2026 年 10 月 16 日所列官方文档为准，不同客户端和内核版本可能有差别。

Surge 与 VLESS 争议是什么

这不是一次已经确认的“大规模密码泄露事件”，而是协议支持和安全配置等问题引发的一系列争论。

2026 年 4 月 14 日，Surge 团队发布关于 VLESS 协议的说明，将 TLS 实现改动、维护成本和稳定性列为暂未合并相关支持的理由。Xray 开发者随后发表了对 TLS 库适配问题的回应。双方对工程实现和技术路线存在分歧，不能仅凭哪一方的声明判定某个协议全面胜出。

争议到 7 月又涉及节点配置安全。Project X 频道 7 月 5 日的公告表达了调整开发关注方向、与部分生态切割的立场；7 月 6 日的帖子则批评部分机场的自签证书配置。7 月 7 日的后续说明进一步提到自签证书没有做证书固定的问题。

这些帖子能说明发帖者的立场，却不能单独证明某家服务商正在窃取数据，更不能把“存在被攻击的条件”写成“已经发生监听”。对普通用户来说，更有用的问题是：自己的配置到底怎么确认节点身份。

自签证书和跳过验证不是一回事

TLS 不只负责加密，还需要让通信双方确认连接对象。否则，即使数据经过加密，也可能是在和冒充服务器的人通信。关于身份认证、保密性与完整性的区别，可参阅 MDN 的 TLS 说明。

常规 TLS 节点可以使用受信任 CA 签发的证书，由客户端检查证书链、名称和有效期。自签证书则不能仅凭公共 CA 信任链证明身份，需要另有可信的认证方式，例如事先通过可信渠道取得并固定服务器证书指纹。

证书指纹可以理解为证书的摘要。客户端只接受预先确认的那张证书，而不是“服务器发来什么就信什么”。Xray TLS 文档提供了 pinnedPeerCertSha256，用于指定接受的证书散列值；证书更新后，也需要通过可信渠道核对新的值。

相反，如果配置跳过证书验证，又没有其他有效的服务器认证，攻击者在能够劫持连接时，就可能冒充节点。Surge 官方对 skip-cert-verify 的说明也明确提示了这种代理连接中间人攻击风险。

要注意，第一次连接时从服务器现场读取一个指纹，再不加核对地信任它，不能证明第一次连接就没有遭到冒充。指纹需要可信来源，而不仅是看起来像一长串正确字符。

节点被冒充会直接泄露网页密码吗

普通代理转发 HTTPS 时，要分清两层连接：

• 代理客户端到节点的连接，保护这一段传输并认证节点。
• 浏览器或 App 到目标网站的 HTTPS，另行认证网站并保护应用数据。

如果第一层被截获，攻击者可能接触代理协议凭据、目标地址等信息，并转发、阻断或干扰流量；具体能看到什么，取决于协议和应用。明文 HTTP 内容尤其需要警惕。

但只要浏览器到真实网站的 HTTPS 身份验证和加密仍正常，截获外层代理连接并不能直接解开里面的账号密码。这不代表可以忽略外层风险，而是不能把两个安全边界混在一起。

另一个常被混淆的功能是客户端的 HTTPS 解密。Surge 的 MITM 文档说明，这项功能需要受系统信任的 CA，并按配置的主机范围处理流量。它与节点里“跳过证书验证”的开关不是同一个设置。

如果有人为了让普通节点连接，要求你安装并完全信任陌生根证书，应先停止操作。系统证书的检查方法可以看本站的根证书用途与风险指南。

如何检查自己的节点配置

先备份当前配置，只检查自己实际使用的节点。不要把订阅链接、二维码、完整配置或日志上传到在线检测网站，它们可能包含账号凭据。

第一步确认当前节点和协议

先在代理页面记下当前选中的节点，再查看对应节点详情或实际生效的配置，避免检查了一个根本没有使用的节点。

使用 Clash 或 FlClash 时，在配置列表找到当前启用的订阅，查看配置预览或在本地编辑器中打开配置，搜索节点名称及其 TLS 字段。若节点来自 proxy-providers，还要查看提供者中的节点内容，不能只在主配置里搜索一次就下结论。

使用 Surge 时，检查当前配置中对应的代理条目；使用 Shadowrocket 小火箭时，进入首页节点右侧的信息或编辑入口，查找 TLS 和证书验证设置。界面没有显示相关选项，不代表一定在验证，仍需结合客户端文档或向服务商确认。

先看协议：下面的常规证书判断主要针对使用普通 TLS 的节点。REALITY 使用自己的认证机制，不应只凭一个跳过验证字段就判定它“完全不认证”，更不要擅自改动公钥、服务器名称等参数。其配置机制见 Project X REALITY 文档。

纯 Shadowsocks 等不使用普通 TLS 证书的连接，也不能因为找不到这些字段就判断为不安全。协议名称、是否抗封锁、是否正确认证服务器，是不同的问题。

第二步区分跳过验证和证书固定

下面列的是检查关键词，不是一份可以直接导入的配置：

客户端或内核	跳过验证的相关字段	证书固定的相关字段
Surge	skip-cert-verify	server-cert-fingerprint-sha256
Mihomo 内核的 Clash 客户端	skip-cert-verify	fingerprint
Xray	旧配置中的 allowInsecure	pinnedPeerCertSha256

Xray 文档已将 allowInsecure 标为弃用选项，不要把旧教程中的字段当作所有新版都支持的设置。小火箭等客户端可能使用界面开关或不同的导出格式，不能照搬上表的字段名称。

检查 Mihomo 配置时，尤其要区分 fingerprint 和 client-fingerprint: chrome：前者是证书指纹，后者控制客户端 TLS 握手指纹，选择 Chrome 指纹不等于验证了节点证书。两者的适用范围见 Mihomo TLS 配置文档。

看到跳过验证为 true，先确认协议和是否启用了有效的固定验证；看到 false，也只能说明这一个开关的状态，不能证明整个节点没有其他安全问题。

第三步核对证书固定的来源

如果服务商声称使用了证书固定，核对它提供的是服务器证书指纹，而不是上一节提到的浏览器握手指纹。按当前客户端文档检查格式，并确认这个值确实被当前使用的节点配置引用。

指纹应通过可信的官网、已确认的支持渠道或其他独立可信方式核对，不要从连接报错里随便复制一个值填进去。证书更换时也要重新核对；拿不准验证是否生效，就把字段名称和客户端版本告诉服务商，请它提供明确说明。

第四步发现疑点后先询问再修改

可以把下面的问题发给服务商，不必发送自己的密码或订阅链接：

这个节点使用公共 CA 证书，还是自签证书？客户端通过什么方式验证服务器身份？如果使用证书固定，请提供适用于当前客户端版本的配置，以及可核对的 SHA-256 证书指纹和更新方式。

如果确认是常规 TLS 节点，且正在跳过验证、没有其他可靠认证，优先暂停使用该节点，并要求修正配置。不要随便填一个指纹，也不要一边保留跳过验证，一边以为填了服务器名称就足够安全。

修改后保存并重新连接，检查日志。证书名称不匹配、未知签发者或指纹不匹配，意味着需要核对配置、证书或连接环境，不应直接把验证再关掉。远程订阅更新后，还要确认修正没有被覆盖；连接成功本身不是安全测试结果。

常见误区

收费贵或使用专线就不用验证证书

价格和线路类型不能替代服务器身份认证。是否需要证书、如何认证，应看协议设计与实际配置，而不是套餐宣传。

使用公共 CA 证书就可以跳过验证

证书本身合格，不代表关闭验证后仍然能识别冒充者。客户端必须实际执行相应的验证，证书才发挥作用。

分流规则可以修复证书问题

分流决定请求走哪个出口，证书验证决定连接对象是否可信，两者不能互相替代。本站的 FlClash 分流教程和小火箭分流教程适合调整出口，不需要为此安装陌生根证书或关闭节点验证。

普通用户应该怎么做

不用根据争论给所有客户端和协议贴上“安全”或“不安全”的标签。先检查当前节点如何认证服务器，再核对浏览器有没有证书警告，以及设备是否装过不明根证书。

可以记住一个顺序：先确认协议，再看验证方式，最后核对配置是否生效。 有疑问就向服务商索取明确配置，不用“能上网”替代安全判断，也不用“可能被攻击”推导出账号已经泄露。