ShadowTLS 是什么：订阅里的节点用什么客户端

ShadowTLS 是什么

ShadowTLS 是一个 TLS 伪装工具，更准确地说，它是一层套在其他代理协议外面的「外壳」。官方 README 的中文介绍把它概括为：一个可以使用别人的受信证书的 TLS 伪装代理。

要理解它，先看一个对比。常见的 TLS 类代理，比如 Trojan，需要服务器有一个属于自己的域名和证书。ShadowTLS 的思路不同：它在握手阶段，把握手过程交给一个真实存在、证书可信的网站去完成。防火墙看到的，是一次与知名网站之间完全正常的 TLS 握手，证书也是那个网站真实有效的证书。README 还提到，如果用浏览器直接打开，看到的也是那个可信域名的正常网页内容。握手结束之后，ShadowTLS 再把后续数据转交给真正的代理服务。

这里的关键是：ShadowTLS 只负责「看起来像正常 TLS」这一件事。README 写得很清楚，项目不包含数据加密，也不负责封装代理请求，这些都不是它的目标。所以它总是和另一个加密代理一起出现，README 举的例子就是 Shadowsocks。

仓库中有 v2 和 v3 两版协议设计文档，sing-box 官方文档的 ShadowTLS 出站则列出了 1、2、3 三个协议版本，并注明密码字段只在 v2 和 v3 中提供。普通用户不需要记住这些差别，只要知道节点里的版本号必须和服务端一致，填错了就连不上。

官方来源核对结果

以下内容于 2026 年 10 月 21 日在官方仓库和 GitHub 接口上直接核对，没有看到的字段写「未能核实」。

字段	核对结果	来源
官方仓库	ihciah/shadow-tls	https://github.com/ihciah/shadow-tls
是否归档	否（archived 为 false）	https://api.github.com/repos/ihciah/shadow-tls
最新版本	v0.2.25	https://github.com/ihciah/shadow-tls/releases/tag/v0.2.25
发布日期	2023-12-13（UTC）	同上
最近一次代码提交	2025-04-25 前后	GitHub 提交记录
许可证	MIT	仓库 LICENSE 文件
发布页平台	Linux（x86_64、aarch64、arm、armv7，musl 构建）、macOS（x86_64、aarch64）	v0.2.25 发布页附件列表
Windows 支持	不支持（README 说明）	官方 README
官方图形客户端	未在官方页面看到	官方 README
官方镜像	README 提到可用 Docker Compose 部署	官方 README

许可证一栏需要补充一句：仓库根目录的 LICENSE 文件是 MIT 许可证全文，GitHub 接口识别结果也是 MIT。

ShadowTLS 现状：长期没有新版本，不推荐使用官方独立程序

这一节是本页最想讲清楚的部分。

仓库没有归档，作者也没有在 README 里宣布停止维护。但从客观记录看，最新正式发布 v0.2.25 是 2023 年 12 月的事，此后没有任何新的发布；2025 年 4 月有过两次小的修复提交，之后仓库再无推送。对一个需要和审查手段持续对抗的伪装工具来说，近三年没有新版本，是一个需要认真对待的信号。

因此，本页的立场是：不推荐普通用户去下载 shadow-tls 官方独立程序来使用。 这不仅是因为更新慢，也因为它本来就不是给普通用户准备的：它没有图形界面，只有命令行，不支持 Windows，还必须和另一个加密代理配合运行。

如果你的机场订阅里确实有 ShadowTLS 节点，更合理的做法是使用内置了 ShadowTLS 支持的主流客户端。这些客户端的 ShadowTLS 实现由各自的内核团队维护，更新节奏跟随内核本身，不依赖 ihciah/shadow-tls 的发布。

ShadowTLS 和机场订阅是什么关系

在机场订阅里，ShadowTLS 通常不会单独出现，而是作为某个节点的附加层出现。以 mihomo 为例，官方文档把 shadow-tls 列为 Shadowsocks 节点的插件之一，与 obfs、v2ray-plugin 等并列。也就是说，在 Clash 系的配置里，一个 ShadowTLS 节点的本体是 Shadowsocks 节点，只是插件一栏写了 shadow-tls，并附带伪装域名、密码和版本等设置。

在 sing-box 的官方文档里，形式又不一样：ShadowTLS 被列为一个独立的出站类型，而不是 Shadowsocks 的插件选项。两种内核描述的是同一类节点，但配置格式互不通用。

这对普通用户意味着：

• 你拿到的订阅格式必须和客户端匹配。Clash 格式的订阅交给 sing-box 系客户端，或者反过来，ShadowTLS 这类组合节点最容易在转换中丢失。
• 节点里出现一个陌生的大公司域名，不代表你在访问那个网站，那只是用来完成握手的伪装目标。
• 机场后台如果同时提供多种订阅格式，选择与你所用客户端对应的那一种。订阅链接的基本概念见 订阅链接是什么。

ShadowTLS 节点应该搭配什么客户端

ShadowTLS 节点要用支持它的内核来跑，目前在官方文档里能确认的有两个：

• sing-box：官方文档中有 ShadowTLS 出站，支持协议版本 1、2、3。使用 sing-box 内核的官方客户端包括安卓上的 SFA、iPhone 上的 SFI、Mac 上的 SFM，内核本身的介绍见 sing-box。
• mihomo：官方文档把 shadow-tls 列为 Shadowsocks 的插件。基于 mihomo 内核的客户端有电脑上的 Clash Verge Rev，内核介绍见 mihomo。

选择时有一个实用原则：按订阅格式选客户端，而不是按协议名选。机场给的是 Clash 格式，就用 mihomo 系客户端；给的是 sing-box 格式，就用 sing-box 系客户端。第三方客户端是否支持 ShadowTLS、支持哪个版本，以它们自己的更新说明为准，本页不替它们背书。

为什么这类伪装不是万能的

ShadowTLS 的设计确实巧妙，但普通用户不宜把它理解成「最安全」或「一定不会被识别」的方案。原因有几层：

一是它的安全性依赖内层协议。外层伪装只负责让握手看起来正常，真正保护数据内容的，是内层的 Shadowsocks 等加密协议。

二是伪装目标的选择属于服务端配置，普通用户无法控制，也无需操心。节点能不能用、稳不稳定，归根到底取决于机场的运维。

三是任何协议的特征都可能随着时间被研究和识别，这也是长期不更新的工具更需要谨慎的原因。

ShadowTLS 节点常见问题排查

订阅里的 ShadowTLS 节点出问题时，表现往往比普通节点更让人困惑，因为它由两层组成，任何一层出错都会导致连接失败。可以按下面的顺序检查：

• 节点有没有被导入。 先在客户端的节点列表里确认 ShadowTLS 节点是否存在。不存在通常意味着客户端不支持这种组合，或者订阅在转换过程中把它过滤掉了。
• 订阅格式是否对应。 用 Clash 格式订阅时，节点会以 Shadowsocks 加插件的形式出现；用 sing-box 格式订阅时，则是独立的出站。两种格式不要混用，也尽量不要经过来路不明的在线转换工具处理。
• 内核版本是否过旧。 ShadowTLS 的 v3 协议比早期版本新，如果客户端内置的内核版本很老，可能不认识 v3 节点。把客户端更新到官方发布的较新版本再试。
• 不要改动伪装域名和版本号。 节点里出现的伪装域名、协议版本、密码都必须和服务端完全一致，这些值由机场设定，普通用户不应修改。
• 用其他节点对比。 如果同一订阅里其他协议的节点都正常，只有 ShadowTLS 节点失效，把客户端名称、版本和出错现象一并告诉机场客服，比自己反复尝试更快。

另外，由于 ShadowTLS 的握手需要服务端与伪装目标网站通信，伪装目标网站本身出现访问异常时，节点也可能受到影响。这属于服务端层面的问题，只能由机场调整。普通用户能做的，是记录出问题的时间和节点名称，反馈给客服，并在此期间切换到订阅里的其他节点继续使用。

下载与安全提醒

如果你出于学习目的要看官方程序，只从 ihciah/shadow-tls 的发布页获取，不要使用网盘或群文件里的打包版本。普通用户真正需要下载的是客户端，而客户端也应当从它们各自的官方仓库或官方商店获取。通用的核对方法见 下载安全指南。

小结

ShadowTLS 是一层借用他人真实证书完成 TLS 握手的伪装外壳，必须和 Shadowsocks 等加密协议搭配，本身不负责加密。官方仓库 ihciah/shadow-tls 没有归档，许可证为 MIT，但最新版本 v0.2.25 停留在 2023 年 12 月 13 日，长期没有新发布，且不支持 Windows，本页不推荐普通用户使用官方独立程序。遇到订阅里的 ShadowTLS 节点，请使用官方文档确认支持它的 sing-box 或 mihomo 系客户端。更多协议对比见 代理协议科普，全部客户端见 客户端列表。