Clash Blog
搜索 K

深色模式

Clash Trojan 协议配置完全指南：真实 TLS 伪装、证书验证与生产级 YAML ​

直接答案：Trojan 协议的设计哲学是**“不创造自定义私有加密协议，直接融入标准 HTTPS 流量之中”**。它摒弃了早期 Shadowsocks/VMess 因对称强加密或特定数据包头导致的指纹暴露，将原始 Socks5 数据包直接包裹在经合规公钥基础设施（PKI / CA 权威机构）签名的标准 TLS 1.3 隧道中。外部主动探测器探测时，其表现与一台托管了真实静态网页的合规 Web 服务器（如 Nginx / Caddy）毫无二致。作为经久不衰的经典稳定协议，Trojan 拥有极高的跨平台生态支持与极强的抗干扰生存能力。

一、Trojan 协议与标准 HTTPS 伪装原理 ​

与早期代理协议试图通过数学混淆来抵抗深度数据包检测（DPI）不同，Trojan 采取了“大隐隐于市”的防御范式。在公网审查系统的视野中，TLS 握手阶段的客户端问候（Client Hello）、服务端响应（Server Hello）、证书交换以及密码套件协商，完全符合标准的 RFC 8446（TLS 1.3）规范：

[客户端发起网络请求]
       |
       v (标准 TLS 1.3 握手，携带合规 SNI: hk01.yourdomain.com 与 uTLS Chrome 指纹)
[Trojan 边缘服务端 (443 端口)]
       |
       | 接收到明文请求前，先解开 TLS 隧道
       | 校验内层 56 字节 SHA224 密码哈希签名
       +------------------------------------+
       |                                    |
   [密码匹配成功]                      [密码校验失败 (审查主动探测)]
       |                                    |
   执行代理流量线速解包                 透明回落 (Fall-through) 至本地 Nginx
   直达目标互联网远程端点               返回合规且具有合法证书的伪装 Web 站点

核心设计细节剖析 ​

  1. 密码哈希校验机制：Trojan 在握手建立后的首包中，发送 56 个十六进制字符的 SHA224 密文散列值（加上 \r\n 换行符），作为身份凭据。只有密码哈希完全一致，服务端才将其重定向至出站代理转发线程；
  2. 主动探测防御 (Fall-through)：当外界审查探针尝试向该 443 端口发起不带密码、或者携带错误密码的 HTTP/HTTPS GET 嗅探时，Trojan 服务端会利用反向代理机制，将连接静默回落到预设的常规 Web 站点（如伪装成个人技术博客或开源文档页面），返回合法的 200 OK 静态 HTML，使审查探测器得出“该服务器仅仅是一台普通网站”的结论。

二、Clash / Mihomo 生产级 Trojan 配置 YAML 模板 ​

在生产级配置中，除了基础的服务器地址与密码之外，必须显式声明 SNI 伪装域名、ALPN 协议协商策略、uTLS 客户端指纹模拟 以及 严格的证书校验：

yaml
proxies:
  # 1. 标准 TLS 直连 Trojan 节点 (推荐用于低延迟专线与高带宽直连)
  - name: "🇭🇰 香港专线 01 - Trojan-TLS"
    type: trojan
    server: hk01.techflow-node.com
    port: 443
    password: "StrongSecretToken2026#Alpha"
    udp: true
    sni: hk01.techflow-node.com
    alpn:
      - h2
      - http/1.1
    skip-cert-verify: false
    client-fingerprint: chrome

  # 2. 结合 WebSocket 传输与 CDN 穿透的 Trojan 节点 (备用容灾场景)
  - name: "🇯🇵 东京备用 02 - Trojan-WS"
    type: trojan
    server: jp02.techflow-node.com
    port: 443
    password: "StrongSecretToken2026#Alpha"
    udp: true
    sni: jp02.techflow-node.com
    skip-cert-verify: false
    client-fingerprint: chrome
    network: ws
    ws-opts:
      path: /websocket-api-v2
      headers:
        Host: jp02.techflow-node.com

关键配置参数深入解读 ​

  • sni（Server Name Indication）：在 TLS 握手阶段对外广播的目标主机名。必须与服务器端绑定的 SSL 证书绑定的完全限定域名（FQDN）严格一致，否则会导致证书校验失败；
  • alpn（Application-Layer Protocol Negotiation）：优先声明 h2（HTTP/2）与 http/1.1，使传输层协商表现更符合主流现代浏览器的真实行为；
  • client-fingerprint: chrome：至关重要的反指纹识别参数。Go 语言原生的 TLS 协议栈在握手密码套件列表、扩展顺序及椭圆曲线支持上具有独特的辨识特征。指定 chrome 指纹后，Mihomo 内核会利用 uTLS 模拟真实 Google Chrome 浏览器的 Client Hello 特征，彻底消除网络中间盒对 Go 语言指纹的阻断；
  • skip-cert-verify: false：生产环境中严禁设置为 true。一旦跳过证书验证，将完全丧失防御中间人攻击（MITM）的能力，使得公网审查系统能够直接劫持并解密您的通信会话。

三、传输协议综合性能对比：Trojan vs VLESS vs Shadowsocks ​

在选择出站协议时，技术团队应根据物理承载介质（IPLC 专线 vs 公网 BGP）与终端算力做出权衡：

评估维度Trojan (标准 TLS 1.3)VLESS (XTLS-Vision)Shadowsocks (AEAD 2022)
伪装隐蔽性极高（原生标准 HTTPS 架构）极高（偷取真实网站证书与流控）中等（在非专线公网容易被重放攻击嗅探）
首包建连延迟较好（TLS 1.3 1-RTT 握手）极致（XTLS 0-RTT / 1-RTT）最低（0-RTT 对称直接转发）
CPU 吞吐损耗中等（单层 TLS 对称加解密）极低（Vision 模式对直接 TLS 流量放行）极低（纯对称轻量密码硬件指令加速）
软路由适配性极佳（通用跨平台客户端原生支持）依赖现代核心（需支持 Xray/Mihomo）极佳（全平台通用）
推荐适用场景跨境公网传输、多端通用配置极限千兆大带宽吞吐、4K 流媒体内网低延迟专线 (IPLC/IEPL) 二层互联

四、生产环境典型故障排查手册 ​

1. 现象：节点连接持续提示 certificate verify failed 或 x509: certificate is valid for..., not... ​

  • 根本原因：节点配置中的 sni 与服务端实际出示的 SSL 证书中的通用名称（Common Name）或使用者可选名称（SAN）不一致。
  • 排查实操： 在本地终端执行 OpenSSL 探测命令，查看服务端真实出示的证书域名：
    bash
    openssl s_client -connect hk01.techflow-node.com:443 -servername hk01.techflow-node.com < /dev/null | openssl x509 -noout -text | grep -A 1 "Subject Alternative Name"
    确认输出中的 DNS 记录后，将 sni: 字段修正为证书完全匹配的域名。

2. 现象：节点导入后延迟测试显示 Timeout，但服务端端口正常开放 ​

  • 根本原因：本地设备系统时间漂移。
  • 技术机理：TLS 1.3 握手对时间有效性有严苛约束。如果本地系统时钟与标准国际时间相差超过 60 秒，TLS 握手将直接判定证书尚未生效或已过期，引发静默建连超时。
  • 修复方法：在 Windows / macOS / Linux 开启网络时间协议（NTP）自动对齐（例如同步至 pool.ntp.org 或阿里云 NTP 服务器）。

3. 现象：网页打开正常，但 Telegram 语音或联机游戏提示网络受限 (NAT Strict) ​

  • 根本原因：未在 Trojan 节点中开启 UDP 转发支持。
  • 修复方法：检查配置中是否显式声明了 udp: true。同时，如果在 Clash 中配置了 TUN 模式，确保系统内核未对 UDP 流量实施丢弃策略。

五、延伸阅读与相关方案 ​