小火箭添加 Trojan 节点：协议原理与 Add Server 参数填写要点

Trojan 的工作方式：先建立 TLS，再进行协议认证

Trojan 将代理协议的数据放入 TLS 加密连接。常见的基础连接使用 TCP：客户端先连接服务器地址和端口，再完成 TLS 握手与证书验证，随后发送 Trojan 认证信息以及目标请求。服务器接受认证后，才继续转发流量。因此，“端口能连接”“TLS 握手成功”“密码认证通过”“目标网站可访问”是不同的检查结果，不能相互替代。

TLS 负责连接加密和服务器身份验证；Trojan 密码负责协议访问认证，两者用途不同。密码正确不能修复证书过期，证书有效也不表示密码正确。服务器使用 443 端口，只能说明它在该端口接受连接，不能据此判断其一定提供 Trojan 服务。

本文以基础 Trojan over TLS 为例。如果服务商还给出了 WebSocket、路径或其他传输参数，仅填写地址、端口和密码可能不足以建立连接。应按同一份完整配置核对，不要将不同项目的 SNI、Password 和传输设置拼接使用。

Add Server 前：准备一份完整参数

手动输入前，先确认资料明确写着 Trojan，而不是仅凭端口或域名推断类型。订阅导入适合保留服务商提供的完整字段；手动添加则适合逐项核对参数。两种方式使用的是同一组连接信息，区别在于由谁负责填写。

• 服务器地址：完整主机名或 IP 地址，不附带 https://、路径或端口。
• 服务器端口：单独提供的数字，例如 443；若资料写的是其他端口，按原值填写。
• Password：保留大小写和全部符号，避免复制时带入首尾空格、换行或引号。
• SNI 与证书要求：记录服务商指定的 TLS 主机名，以及是否有额外信任配置。
• 附加传输参数：若资料包含传输类型、Host 或路径，先确认当前项目需要哪些字段，再进入对应选项填写。

Home → Add Server：逐项填写地址、端口与密码

在 Home 点右上角的添加按钮，进入 Add Server，将 Type 设为 Trojan，再填写下表项目。字段的排列与可见附加选项以当前应用界面为准；应以字段含义核对资料，而不是照着某张旧界面的位置输入。

1. 先填写 Type、Address 和 Port，确认 Address 中没有重复写入端口。
2. 粘贴 Password，核对字符是否完整。手动填写密码字段时应使用密码原文，而不是自行进行 URL 编码。
3. 按资料设置 SNI，核对证书验证选项；存在附加传输要求时，一并填写。
4. 保存后回到 Home，选中刚添加的项目，再启用连接。若系统请求添加 VPN 配置，按系统提示确认。

端口相同不代表参数可以互换，修改 Port 也不会自动修改服务端监听设置。若资料没有提供端口，先向你的服务商确认，而不是连续尝试多个常见端口。Password 同样不是应用购买密码，也不是设备解锁密码。

SNI 与证书校验：地址相同不等于身份相同

Address 决定连接到哪里；SNI 是 TLS 握手中的服务器名称提示，用于服务器选择相应站点与证书。在常规域名配置中，客户端还需要验证证书是否可信、是否在有效期内，以及证书中的名称是否匹配预期身份。SNI 本身不是密码，也不是给证书增加信任的开关。

例如，连接地址为某个 IP，而服务器证书签发给 tls.example.com 时，不能简单把该 IP 当作证书名称。反过来，随意填写一个无关网站域名，也不会使服务端拥有对应证书或自动完成站点配置。SNI 必须是该连接实际支持的名称。

自定义证书或特殊信任设置需要单独核对信任方式。不要为了让报错暂时消失而将跳过证书验证作为长期配置。TLS 已建立也只说明客户端到该服务器的这一段连接状态，不代表所有目标网站都可访问。

保存后验证：把协议问题与规则问题分开

添加成功只代表本地资料已保存，不等于服务器已经认证成功。应先检查选中的项目和 Global Routing，再进行一次可重复的访问测试。在 Config 下，请求按配置规则选择策略，部分请求可能使用 DIRECT，因此某个网页能打开并不能单独证明 Trojan 可用。

1. 确认选中项目：回到 Home，核对当前选择的是刚保存的 Trojan 项目，而不是列表中的其他项目。
2. 确认路由姿态：在 Global Routing 中查看当前使用 Proxy、Direct、Config 还是 Scene。Direct 不适合验证该代理；Scene 应先核对其实际采用的策略。
3. 做隔离测试：确有需要时短暂切到 Proxy，使用自己有权访问的已知 HTTPS 页面测试；完成后恢复原先设置。Proxy 只用于排除规则分流变量，不会修复错误密码。
4. 检查请求记录：结合请求记录与可用错误信息，区分解析、建立连接、TLS 和后续转发阶段。测试数值应按测试类型解读，延迟读数本身不是完整可用性证明。
5. 回到 Config 复核：若 Proxy 可用而 Config 下异常，检查规则顺序与对应策略，确认该请求是否真正选择了预期的代理。

规则通常自上而下匹配，首条命中后使用对应策略。以下是规则语义示意，不是建议覆盖现有 Config 的完整配置；示例中的 PROXY 必须在实际配置中对应可用策略。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

这段示意将 example.com 及其子域名交给 PROXY，其他未命中请求交给 DIRECT。若仅用其他域名测试，可能完全没有经过 Trojan。相同原则也适用于配置中的 GEOIP、IP-CIDR 等规则：先确定请求命中了什么，再判断出站参数是否有问题。FINAL 应放在规则末尾。

常见问题：按失败阶段检查，而不是反复重建

下面列出的是排查方向，不是对单一报错的绝对判定。同样的超时可能来自地址不可达、服务器未响应或后续请求无响应；需要把错误信息与发生阶段放在一起看。