2026年Trojan协议完全指南：三条部署路线、TLS证书签发与被封后的迁移全流程

搜 Trojan 教程的人，卡住的地方其实很集中：到底装哪一个版本、证书怎么签才不会被客户端嫌弃、封了以后先动哪一层。这三个问题在 2026 年的答案，和 2020 年网上流传的那些一键脚本已经不太一样了。

先摆事实。Trojan 的官方 C++ 实现（trojan-gfw/trojan）最后一次发版是 2020-06-10 的 v1.16.0，仓库还有零星提交，但没有新 release；Go 分支 trojan-go 停在 2021-09-14 的 v0.10.6；真正还在往前走的，是 Xray 内核里的 trojan 入站（v26.3.27，2026-03-27 发布）和 Jrohy 的多用户管理脚本（v2.15.3，2023-09-24）。协议本身一字节没改——变的只是外面那圈工具链。这个判断很关键：网上大量"Trojan 已死"的说法，说的是某一个实现停更，不是协议失效。

但也要把丑话说在前面。自建的真正成本不在装，而在装完之后每个月都要管的几件事：证书到期前有没有自动续、回落站点是不是还在正常响应、IP 有没有进小黑屋。如果你要的只是每天能用的一个出口，把这些活儿外包给订阅更划算——瑶瑶领先的入门档 ¥9.9/月给 384GB，先跑一个月看够不够用，比先买台 VPS 再发现用不上要省事得多。两条路不冲突：本文讲的是自建这条路上真实存在的坑。

一、58 字节的接头：Trojan 协议到底长什么样

Trojan 的整个设计就一句话：把代理请求伪装成一次普通的 HTTPS 访问。客户端先和服务端做一次真正的 TLS 握手——用真证书、真域名、真 SNI，握手失败就像任何 HTTPS 服务器一样直接断开。握手成功之后，客户端才在隧道里发送真正的请求头：

+------------------------+---------+----------------+---------+----------+
| hex(SHA224(password))  |  CRLF   | Trojan Request |  CRLF   | Payload  |
+------------------------+---------+----------------+---------+----------+
|          56            | X'0D0A' |    Variable    | X'0D0A' | Variable |
+------------------------+---------+----------------+---------+----------+

Trojan Request = CMD(1) + ATYP(1) + DST.ADDR(变长) + DST.PORT(2)
  CMD : 0x01 = CONNECT（TCP 直连）  0x03 = UDP ASSOCIATE（UDP 转发）

SHA224 的十六进制摘要是 56 个字符，加上结尾的 CRLF 正好 58 字节。本机可以立刻核一遍，不用信我：

python3 -c "import hashlib; h=hashlib.sha224(b'your_password').hexdigest(); print(h, len(h), len(h)+2)"
# 输出形如 7fbf5c43...f3d16 56 58

这 58 字节不是背下来的冷知识，它解释了一个很实用的问题。Xray 的文档在写 trojan 入站的 fallbacks 时，给出的触发条件是「首包长度 < 58，或第 57 个字节不是 \r，或身份认证失败」。58 就是接头长度；第 57 个字节（从 0 数起是第 56 位）正是 CRLF 里的 \r。也就是说，回落判定用的就是接头本身的字节特征——这比"密码对不对"更早生效，探测者连密码都不用猜就能被引到别处。

接头之后的 Payload 有一个容易被忽略的设计：官方协议文档明确写了，第一个数据包会捎带上 payload，目的是避免"首包长度固定"这种模式被统计出来。这是 Trojan 对抗被动检测的核心手法之一，也是为什么它当年被叫作"不可识别"。

由此可以推出三件事，后面每一节都建立在这三条上：

证书不是可选项，是协议的一部分。服务端 443 必须是一张 TLS socket，证书不对，握手就废，代理根本不成立。
fallback 端点决定了别人探测你时看到什么。官方服务端配置里 remote_addr 默认 127.0.0.1、remote_port 默认 80——如果你那台机器上 80 口没有真站点，探测者拿到的就是连接被重置，这比任何指纹都好认。
UDP 是附带能力，不是必然能力。0x03 走的是 UDP ASSOCIATE，但如果流量被塞进 CDN 的 WebSocket 隧道，UDP 就断了。

想先看清 Trojan 在五六个主流协议里的位置（特征、性能、可维护性三个维度各自付出什么代价），可以对照主流代理协议横评那张表；本篇只处理 Trojan 这一条线从装到迁移的完整流程。

二、三条部署路线：先选实现，再谈配置

同样叫"装 Trojan"，三条路线的产物、维护方式和出问题时能查的东西完全不同。先把它们的现状摊开：

路线	实现与维护状态	适合谁	主要代价
路线 A：官方二进制	C++ 实现，最后一版 v1.16.0（2020-06），无新功能但协议最原味	单人单机、想要"每一行配置都看得懂"的人	全靠手工：systemd、证书续期、多用户都没有现成的
路线 B：Jrohy 管理脚本	Go 实现 + Web 面板，v2.15.3（2023-09），集成 acme.sh	要给几个人分账号、要看流量和期限的人	脚本替你做了很多决定，出问题先得搞懂它铺了哪几层
路线 C：Xray 的 trojan 入站	仍在活跃维护（v26.3.27，2026-03），与 VLESS/REALITY 同一内核	要和别的协议共存、想用完整 fallbacks 分流的人	配置文件比原版复杂，概念更多（用户、回落、传输层）
变体：trojan-go	v0.10.6（2021-09），支持 WebSocket/CDN、多路复用、二次加密	一定要套 CDN 中转的人	已停更，新特性只能靠别的实现补

选型其实只有三个问句：是不是只有你一个人用（是→路线 A）、要不要给别人开账号并且看流量（要→路线 B）、这台机器上还想不想跑别的协议（想→路线 C）。三个都否，任选一个顺手的；三个都想要，那答案通常是路线 C 打底、路线 B 管人。

还有一个更前置的问题值得先问自己：你需要的是"一台自己能修的机器"，还是"一个能用的出口"。这两件事的价格差得很远。像 SS-ID 这类纯 IEPL 订阅，客户端里填一条链接就能用，官方也支持 OpenWrt、梅林这类平台——它替代不了自建的可控性，但对"只想稳定上网"这个需求来说，省掉的是整条证书与回落链路的维护。

三、路线 A：官方二进制，最透明也最费手

官方实现的配置是纯 JSON，字段少、语义直白，非常适合用来理解 Trojan 到底需要什么。装法就是从 release 页拿 v1.16.0 的对应架构包，解开得到单个可执行文件，扔进 /usr/local/bin/trojan，配一个 systemd 单元。

服务端配置（/etc/trojan/config.json）里真正决定成败的是这几项：

{
  "run_type": "server",
  "local_addr": "0.0.0.0",
  "local_port": 443,
  "remote_addr": "127.0.0.1",
  "remote_port": 80,
  "password": ["一个足够长的密码"],
  "ssl": {
    "cert": "/etc/ssl/fullchain.pem",
    "key": "/etc/ssl/privkey.pem",
    "alpn": ["http/1.1"],
    "session_ticket": false
  }
}

remote_addr / remote_port：这就是 fallback 端点。指向本机 80 口的真站点，探测者看到的才是一个网站；指向一个空端口，等于告诉对方"这里不是网站"。
password：是数组，但服务端只认第一个（客户端配置文档里明确写了「only the first password in the array will be used」），别以为多写几个就是多用户。
ssl.cert：官方文档的建议是用全链证书（full chain），不是只给站点证书。少中间证书时，一部分客户端会握手失败，而你的浏览器可能没事——这是最容易怀疑人生的那种故障。
ssl.alpn：服务端默认只回 http/1.1。如果前面的 nginx 也想跑 h2，需要用 alpn_port_override 把 h2 的请求转到另一个端口。
session_ticket：默认 false。这个默认值后面第八节还会提到，因为它是一处可观测差异。

systemd 单元没什么花样，ExecStart=/usr/local/bin/trojan -c /etc/trojan/config.json，配 Restart=on-failure 就够。上线后按顺序验三件事：ss -lntp | grep 443 看监听；openssl s_client -connect 你的域名:443 -servername 你的域名 看握手和证书链；不带 Trojan 接头直接访问 443，看能不能拿到 fallback 站点的正常页面——这一步就是在自己扮演探测者，拿不到网页说明回落没配好。

这条路线的短板很明确：多用户、流量统计、期限管理一概没有，全得自己写。如果你连"从零买机器到跑通第一份配置"这条更长的链路都还没走过，先看自建 VPN 全教程把地基铺好，再回来抠 Trojan 的细节。

四、路线 B：Jrohy 脚本，把多用户和证书一起接走

Jrohy 的 trojan 脚本解决的是"一个人管多个账号"这件事。安装是一行：

source <(curl -sL https://git.io/trojan-install)
# 装完后输入 trojan 进入管理程序
# 浏览器访问 https://你的域名 是 Web 管理面板

它能做的事比"装个服务端"多不少，值得逐条对照自己的需求：

两种管理方式：命令行（trojan add / del / info / log / port / tls / update）和 Web 面板，面板里能看在线日志。
流量统计与限制：每个用户单独计量，可设上限；还能限制使用期限。
集成 acme.sh 证书申请：trojan tls 走的就是第六节那套 ACME 流程，省掉自己写续期脚本。
trojan 与 trojan-go 随时切换：需要 WebSocket 套 CDN 时切到 Go 版即可。
分享与订阅：生成 trojan:// 链接和二维码，面板里还能转成 Clash 订阅地址导入客户端。

它的代价是"抽象层"。脚本会自己装 nginx、自己申请证书、自己安排 443 和 80 的归属，装完你拿到的是一个能用的系统，但里面铺了几层需要花十分钟看清——出故障时，trojan log 是第一入口，其次是 systemctl status trojan 和 nginx 的配置。另外它有两个前置条件必须提前满足：域名已经解析到这台机器（脚本要靠它签证书），80 口能被 ACME 用（否则申请会失败，得改用 DNS 模式手工处理）。数据在 MariaDB/MySQL 里，trojan export 和 import 是迁移或备份时的正经出口，别去直接改库表。

五、路线 C：Xray 的 trojan 入站，还在维护的那条

Xray 官方安装脚本是一行，走 systemd 体系：

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
# 落地位置：/usr/local/bin/xray、/usr/local/etc/xray/*.json、/var/log/xray/

入站配置的骨架很短，但每个字段都有含义：

{
  "inbounds": [{
    "port": 443,
    "protocol": "trojan",
    "settings": {
      "users": [{ "password": "一个足够长的密码", "email": "you@example.com" }],
      "fallbacks": [{ "dest": 80 }]
    },
    "streamSettings": { "network": "tcp", "security": "tls",
      "tlsSettings": { "certificates": [{ "certificateFile": "fullchain.pem", "keyFile": "privkey.pem" }] } }
  }]
}

users 是数组，email 用来区分用户（多个用户时不能重复），这才是真正的多用户；fallbacks 可以写多条，按路径或 ALPN 分流到不同的本地端口——这就是为什么想在同一条 443 上同时跑 trojan 和 VLESS，选它最省事。

而 Xray 文档里有一句警告，是全文最该被记住的技术事实：Trojan 必须配合传输安全 TLS 使用；公网环境下还要求启用 Mux，否则一旦内层载荷本身也是 TLS，就会形成 TiT（TLS-in-TLS），很容易被检测，文档还附了 PoC。这句话点破了 Trojan 的结构性软肋：你的隧道里跑的几乎全是 HTTPS，于是隧道本身是一层 TLS、里面的目标站点又是一层 TLS，两层叠在一起。原版协议靠"首包捎带 payload"缓解长度模式，但缓解不等于消除。

顺带说一句多实例：xray@a.service 配合安装时设的 JSONS_PATH，可以让一台机器跑多个互不干扰的实例（每个实例一个目录），做多入口或灰度迁移时很方便，比复制多份 systemd 单元干净。

六、软件层之外：出口 IP 的属性是改不掉的那一层

三条路线折腾的都是"软件怎么搭"，但决定"这条线看起来像什么"的还有一个变量，任何配置都改不了：出口 IP 的归属。你在 VPS 上跑 Trojan，出口就是这台机器的机房 IP，它的属性由 ASN 和这个网段的历史决定——换端口、换域名、换协议、甚至换一台同机房的机器，都不会改变它属于"数据中心"这件事。绝大多数用途（查资料、用 AI 工具、看流媒体）机房 IP 完全够用，不必在这上面焦虑；但有一类需求对"像不像家宽"很敏感：平台风控、多账号运营、需要"干净身份"的登录场景。

这一层是可以自查的，不用猜。把出口地址丢进 ipinfo.io 的 JSON 接口（curl -s https://ipinfo.io/1.2.3.4/json），看 org 字段里是 AS... 的机房/云厂商，还是住宅宽带运营商；再看同一网段有没有被"前手用脏"——后者没有公开数据库可查，只能靠目标平台的实际反馈（登录验证、风控提示、封号记录）来判断。这也是为什么"我这台机器好好的，怎么某平台就是登不上"这类问题，答案经常不在 Trojan 的配置里。

真要一个住宅/原生属性的出口，解法不是再搭一台 VPS，而是换出口类型：住宅代理服务，或者提供住宅/原生 IP 线路的机场订阅——仙路湾的定位就在住宅 IP、原生 IP、跨境多账号与流媒体解锁这一侧。代价和自建正好相反：可控性低、单价高，但省掉了机器、证书、回落这一整套。本文的主线仍然是软件层，这条边界放在这里，是因为后面判断"被封"和"要不要迁移"时，绕不开它。

七、TLS 证书怎么签：五种模式与四个必踩的坑

证书这一节是自建 Trojan 最容易翻车的地方，因为它牵扯三个东西的占位：ACME 验证要用的端口、Trojan 自己占的 443、以及 fallback 站点占的 80。先按"哪个端口空着"选模式：

模式	命令要点	前提	什么时候选它
standalone	`acme.sh --issue -d 域名 --standalone`	80 口空闲	机器上没有 Web 服务，最简单
standalone + ALPN	`acme.sh --issue -d 域名 --alpn`	443 口空闲	443 只留给 trojan、80 被别的东西占着
webroot	`acme.sh --issue -d 域名 -w /站点根目录`	已有站点 + 写权限	80 口有真站点在跑（fallback 就是它）
DNS API	`export CF_Token=...; acme.sh --issue -d 域名 --dns dns_cf`	域名托管商有 API	最省事，不占任何端口，泛域名也靠它
nginx / apache	`acme.sh --issue -d 域名 --nginx`	本机装了对应服务	本来就有反代，顺手复用

对 Trojan 场景来说，DNS API 通常是首选：它既不需要 80 空闲，也不需要 443 空闲，证书签发和你的服务端口彻底解耦。如果域名托管在 Cloudflare，CF_Token + --dns dns_cf 两条命令就能跑通，续期也自动。

证书这件事，本质上是一次性的手艺活加上每月的看护。如果你的场景里"这台机器只是给你自己用"，那么把证书、回落、续期整条链路交给走自家客户端的服务（比如自由猫）也算一种合理分工：它不适合塞进软路由，但"客户端装上就能用、不用管证书"这件事，确实省掉了本节的全部内容。

接下来是四个必须提前知道的坑：

acme.sh 的默认 CA 不是 Let's Encrypt。它的文档写得很清楚，默认签的是 ZeroSSL；要 LE 得显式指定 --server letsencrypt。这本身不是问题（ZeroSSL 的证书同样被主流客户端信任），但如果你在照抄某个只适用于 LE 的排查思路，会找不到对不上的地方。
不要直接让 trojan 读 ~/.acme.sh/ 里的文件。acme.sh 的 README 明确说了那个目录是内部使用、结构可能变，必须用 --install-cert 把证书复制到生产路径：

acme.sh --install-cert -d 你的域名 \
  --key-file       /etc/ssl/privkey.pem \
  --fullchain-file /etc/ssl/fullchain.pem \
  --reloadcmd      "systemctl restart trojan"

--reloadcmd 不是可选项。acme.sh 默认在签出后第 60 天左右续（DEFAULT_RENEW=60，也就是 90 天证书到期前 30 天；它装在 cron 里每天检查一次、到点才真签），续期成功后它只会复制文件；不 reload，进程手里还攥着旧证书，表现就是"证书明明续了，客户端还是报过期"。这一条同样适用于 nginx 和 Xray。
Let's Encrypt 有硬限额，调试别在生产域名上反复失败。官方文档的口径是：每个注册域名 7 天内最多 50 张（回补速度 1 张/202 分钟）；完全相同的标识集合 7 天内最多 5 张（回补 1 张/34 小时）；每个账号 3 小时内最多 300 个新订单（回补 1 个/36 秒）。反复重装客户端、每次删掉 ACME 配置重来，是最常见的撞限额姿势——调试期请用 staging 环境。

签完之后别只看浏览器。用 openssl s_client 看四个字段就够了：subject=（证书上的域名）、issuer=（谁签的）、Verify return code（是不是 0）、以及协商出来的协议版本与 ALPN。我在本机对 www.cloudflare.com 跑过同一条命令，输出形如 subject=CN = ...、New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384、ALPN protocol: h2、Verify return code: 0 (ok)——具体套件与签发者会随站点配置和时间变化，你要看的是这四个字段有没有、对不对，而不是记住某一次的值。

八、"被封"到底封了什么：三种形态与可观测特征

大家说的"被封"其实是三种完全不同的处置，处理方式差得很远。分不清就换机器，是最常见的浪费。

形态	表现	自查判据	典型处置
IP 级封禁	整台机器失联，连 SSH 都不通，ping 无回应	同机非代理端口（22）也不通；从境外另一台机器访问同一 IP 正常	换 IP 或换机房，与协议无关
端口/协议识别	443 能连上、TLS 握手也成，但代理不工作；换端口有时立刻恢复	同一域名换 `8443` 后客户端能连；443 上的连接很快被 RST	换端口、加混淆/多路复用、考虑换协议
主动探测暴露	平时能用，但"被访问过"之后开始不稳	不带 Trojan 接头访问 443，拿不到 fallback 页面或握手异常	把 fallback 换成真站点，补齐 nginx 与证书

第三类最值得说，因为它是自己造成的。Trojan 反主动探测的全部依赖就是"不认识的流量交给 fallback 端点"，而官方默认值是 127.0.0.1:80——如果那台机器 80 口空着，任何一次探测都会得到"TLS 握手成功，然后连接被重置"，这跟一个真正的网站服务器的行为完全不同。补齐的方式很朴素：一个 nginx、一张匹配的证书、一个真能打开的页面。这件事的成本是十分钟，不做的话后面所有关于"抗封锁"的讨论都是空谈。

再说被动侧。Trojan 的流量在 DPI 眼里就是一条 443 上的 TLS 连接，所以能观察的只剩 TLS 参数与流量形态。可以自己核对的差异有几处：

证书与 SNI 是否一致。自签证书、或用 A 域名签的证书去接 B 域名的 SNI，在被动观察里就是一个显眼的错配。官方配置文档也把 verify_hostname 标为强烈建议开启。
ALPN 协商结果。原版服务端默认只回 http/1.1，而 2026 年的主流站点基本都会选中 h2。一台"永远只谈 http/1.1"的 HTTPS 服务器，本身就是少数派。
TLS 套件列表。官方客户端配置里那串默认 cipher 一共 15 项，其中 9 项属于 CBC/静态 RSA 家族（含 DES-CBC3-SHA），TLS 1.3 另有 3 项。而主流浏览器早已剔除 3DES 和静态 RSA 密钥交换——默认值不改，你的 ClientHello 就比浏览器"老"。这属于配置层事实，不是猜测。
会话票据。原版客户端与服务端配置里 session_ticket 默认都是 false，而主流 HTTPS 服务端通常会下发 NewSessionTicket 支持恢复。同样是默认值带来的差异。
流量形态（TiT）。前面引用过的那句 Xray 警告：隧道里套 TLS 会形成 TLS-in-TLS，官方认为这很容易被检测，并建议公网启用 Mux。这一条不是配置瑕疵，而是协议结构决定的，也是这些年 REALITY、Hysteria2 分流走红的原因之一。

需要划一条边界：以上都是"你可以自己观察到的差异"，不等于"某条审查链路一定按这个判断"。真正能确定的是三件事——IP 是否整段失联、443 上的连接是否被快速重置、去掉接头后 fallback 是否还像个网站。把这三件查清楚，比讨论"GFW 用了哪种算法"有用得多。要理解这些手段在时间轴上的先后与各自的效力边界，可以看GFW 封锁演进复盘；而如果已经是"整台机器失联"这种最彻底的情况，处置顺序在VPS 被墙了怎么办里，本篇不重复。

九、迁移：五步换线，每一步的代价都不一样

被封之后的正确顺序不是"先把能改的都改了"，而是按代价从小到大、按诊断结论决定停在哪一步。

顺序	动作	耗时	能解决什么	代价
1	换端口（443 → 8443 之类）	几分钟	只针对端口级处置	客户端配置要同步改；部分网络环境对非标端口更敏感
2	换域名并重签证书	半小时	域名/SNI 被标记的情况	证书要重签，客户端要换地址，旧订阅全部失效
3	换 IP（同商家换 IP 或换机房）	几小时到一天	IP 级封禁	花钱；换机房等于线路质量重抽一次
4	上 CDN 中转（WebSocket）	半天	源站 IP 暴露与部分路径问题	延迟上升、UDP 基本不可用、要维护回源规则
5	换协议（REALITY / Hysteria2）	半天	TLS 层特征被针对	等于重搭一次，客户端也要换配置

走到第 3 步时，有个判断必须先做：问题出在"这台机器"还是"这个出口的属性"。前者换 IP 就好；后者换多少台机房机器都一样——第六节讲过的那条边界，在迁移阶段会以"怎么换都不稳"的形式重新出现。

不管停在哪一步，迁移完有一份五项清单必须过：客户端能连且能打开网页；openssl s_client 的 Verify return code 是 0；不带接头访问 443 能看到 fallback 页面；需要 UDP 的场景实测过 UDP 是否还通（上 CDN 后通常不通）；旧的分享链接、二维码、订阅地址全部更新或作废。第 4 步的细节（端口限制、证书两条路线、优选 IP）在CDN 中转完全指南里；第 5 步如果选 REALITY，配置差异见Xray REALITY 完全指南——它不是换一个协议名那么简单，目标站点的选择本身就是一门功课。

十、FAQ：八个最常被问到的具体问题

Q1：Trojan 和 VLESS + REALITY 现在哪个更难被封？
结构上 REALITY 更主动：它连"证书要自己签"这件事都省了，直接借用目标站点的证书链，握手过程与真实访问难以区分；Trojan 依赖你自己维护的证书与回落站点，做得好可以很像，做得糙就很显眼。但难度不是选型的唯一维度——Trojan 的生态更成熟（几乎每个客户端都支持），排障资料也多。

Q2：一定要有域名吗？
要。证书要对一个域名签发，SNI 也要对得上，用 IP 直连会让证书校验无处落脚。域名成本一年几十块，是这条路上最便宜的一环。

Q3：能用自签证书吗？
技术上能，客户端关掉校验即可，但这就同时放弃了"看起来像 HTTPS"的最大优势：证书不受信任、签发者为空，被动观察一眼就能分辨。原版客户端配置里 verify 和 verify_hostname 都被标为强烈建议开启，是有原因的。

Q4：客户端显示连上了，但打不开网页，先查什么？
先查服务端有没有真的转发出去：curl -x socks5h://127.0.0.1:1080 https://ifconfig.me 在服务端本机跑一次，确认出网正常；再查 fallback 之外最容易忽略的一项——sysctl net.ipv4.ip_forward 和 NAT 规则（如果流量要经过转发）。如果只是部分站点打不开，问题通常在 DNS，而不在 Trojan。

Q5：nginx 和 trojan 抢 443 怎么办？
两种正解：让 trojan 直接监听 443、把 fallback 指到 nginx 的 80；或者让 nginx 用 stream 模块在 443 上按 SNI 分流，trojan 退到本地高位端口。前一种简单，后一种能多站点共存。别做的是让两个进程都监听 443 然后指望它自己协商。

Q6：套 CDN 之后 UDP 还能用吗？
基本不能。CDN 的 WebSocket 中转承载的是 TCP 语义，UDP ASSOCIATE 这条路径会断。需要 UDP 的场景（语音、游戏、部分 QUIC 应用）要保留一条不走 CDN 的直连入口。

Q7：多用户和流量统计怎么做才不折腾？
要么用路线 B 的面板（开箱有流量与期限），要么用路线 C 的 users 数组加统计接口自己接。原版二进制的 password 数组只有第一个生效，不要拿它当多用户方案。

Q8：2026 年还值得新搭一个 Trojan 吗？
看目的。学协议、做可控的单人出口、或者需要在老旧设备上跑一个兼容性最好的方案，值得；追求"最新最强抗封锁"，同门的 REALITY 与 Hysteria2 各有更明确的优势。真要长期稳定使用又不想维护，把这件事外包给订阅是更务实的选择。

十一、一页判断清单

最后把整篇压缩成能贴在手边的几条：

装之前先决定路线：单人 → 官方二进制；多人 → Jrohy 脚本；要多协议共存 → Xray 入站；必须套 CDN → trojan-go。
证书优先用 DNS API 模式签，避开端口占位问题；签完必须 --install-cert + --reloadcmd。
服务端 ssl.cert 用全链，客户端 verify_hostname 保持开启。
fallback 端点必须是真站点，装完自己不带接头访问一次 443 验证。
被封先分类：整机失联 → 换 IP；443 被重置 → 换端口/加混淆；探测后被盯 → 修好 fallback。
迁移按代价递增走：端口 → 域名 → IP → CDN → 协议，别一上来就重搭。
2019 年的那批一键脚本还在网上流传，它们装的实现多半已经停更；用之前先看一眼 release 日期。

Trojan 这个协议的价值从来不在"快"或"新"，而在于它把"像不像一个正常网站"这件事拆成了几个可以自己检查的开关：证书、SNI、ALPN、回落。这些开关你能验，别人也能验——所以它到今天仍然是一个适合用来理解代理与审查如何互相观察的样本。