SOCKS5 出站教程
单个 AnyTLS / Trojan 节点使用 SOCKS5 出站
适用版本与作用范围
适用于 oo v1.0.16-dev.20260925 及包含同项功能的后续版本。本教程使用机器模式、singbox 内核，示例节点 ID 为 237，入口为 node.example.com:11449。示例域名、IP、账号密码均需替换，不是可直接使用的线路。
客户端仍连接原来的 AnyTLS 或 Trojan 入口。只有选中的子节点把用户代理流量转交给 SOCKS5，其他子节点、面板地址、用户认证、证书和 Nginx 路由不因此改变。
客户端 → AnyTLS 节点 237 :11449 → SOCKS5 出口 → 目标网站
原 AnyTLS 节点 :11443 → 保持原出口
原 Trojan 节点 :443 → 保持原出口范围由“机器实例目录 + 节点 ID”共同确定。两个面板即使节点 ID 相同，只要使用不同实例目录，也不会互相覆盖。
目前这是配置文件功能，没有新增“SOCKS5 设置”菜单。不要把出站配置写到整个实例的公共 kernel.custom_config 中，否则该实例下的其他节点也可能继承它。
第一步：升级并确认版本
旧版本不认识单节点覆盖文件，可能继续直连。先升级，再配置；不要降级后继续启用带专用出口的节点。
curl -fL https://node.xboardnext.com/oo/dev/install.sh -o /tmp/oo-install.sh && sudo bash /tmp/oo-install.sh upgrade --version v1.0.16-dev.20260925
sudo oo version首次升级旧命名安装，请使用上面的完整安装器升级命令，不要仅替换核心或使用旧版菜单里的下载地址。升级器会检查旧服务、备份并迁移到 oo.service；发现两套安装或自定义服务时会停止，需先核对。
升级会重启共享节点进程，现有连接会短暂重连。配置、凭据、证书、单节点覆盖文件和既有共享 Nginx 配置应保留；先备份并安排合适的更新时间。
第二步：在面板创建独立入口
新节点绑定后可能立即按原出口启动。完成停用、配置、恢复和出口 IP 验证之前，不要分发或使用这个新节点。
在现有机器下新增 AnyTLS 节点，选择该机器 ID；设置正确的 TLS 域名，并使用尚未占用的服务端口。例如已有 AnyTLS 使用 11443，新节点就使用 11449。直接监听时，连接端口与服务端口均填写 11449，同时放行服务器防火墙和云安全组的 TCP 11449。
同一机器实例、相同域名、自动 ACME 模式可以复用已有有效证书，不需要为了新增端口另申请证书。不同机器实例、手工证书和不同域名不保证共享。证书正常不代表代理流量已可用，仍要完成后面的认证访问测试。
新增独立 AnyTLS 端口不需要让 Nginx 再占用这个端口，也不要停用其他网站使用的 Nginx。节点入口协议仍是 AnyTLS，不要为了配置 SOCKS5 出口把入口协议改成 socks。
第三步：找到正确的机器实例和节点
sudo oo list
sudo oo nodes list记下目标节点对应的完整 INSTANCE 值。节点 ID 不是机器 ID，也不是监听端口。
同时在节点启动日志中确认 effective_kernel=singbox；若显示 xray，不能直接使用本页 JSON。尤其是曾经手动指定 Xray 的 Trojan 实例，不要仅根据协议名称判断内核。
在 /etc/oo/config.yml 中找到该实例已有的 kernel.config_dir。默认形如 /etc/oo/instances/INSTANCE_ID，但以实际配置为准。不要覆盖或公开这个主配置文件，它可能引用敏感凭据。
单节点覆盖文件的固定位置是：
<该实例的 kernel.config_dir>/node-237/kernel.override.json例如默认目录结构下：
/etc/oo/instances/INSTANCE_ID/node-237/kernel.override.json下面命令中的 INSTANCE_ID 必须替换为实际完整实例名称；节点 ID 和端口也要按自己的部署修改。先以 root 权限备份目标实例目录，备份保存在网站目录以外，不要上传到公开托管。
第四步：只停用待配置的子节点
sudo oo nodes delete --instance INSTANCE_ID --node-id 237 --yes
sudo ss -lntp 'sport = :11449'这里的 delete 表示仅本机停用，保留面板数据和本地配置；不是 purge，不会删除实例。等待节点停止，确认 11449 已无监听后再修改。如果仍有监听，应核对进程与端口，不要继续覆盖配置。不要使用 --all。
第五步：填写 SOCKS5 出口
确认上述实际节点目录存在，使用编辑器创建 kernel.override.json。例如默认目录下可使用：
sudo nano /etc/oo/instances/INSTANCE_ID/node-237/kernel.override.json粘贴以下完整 JSON，并替换 SOCKS5 地址、端口、账号和密码。192.0.2.10 是文档示例 IP，不能作为真实出口。
{
"outbounds": [
{
"type": "socks",
"tag": "node-237-socks",
"server": "192.0.2.10",
"server_port": 1080,
"version": "5",
"username": "CHANGE_ME_USER",
"password": "CHANGE_ME_PASSWORD"
}
],
"route": {
"final": "node-237-socks"
}
}无需认证的 SOCKS5 可以删除 username 与 password 两行，注意 JSON 最后一项不能保留多余逗号。含双引号或反斜杠的密码要使用正确的 JSON 转义。不要把真实密码放进命令参数、公开教程或截图。
限制文件权限并检查 JSON 语法：
sudo chmod 600 /etc/oo/instances/INSTANCE_ID/node-237/kernel.override.json
sudo python3 -m json.tool /etc/oo/instances/INSTANCE_ID/node-237/kernel.override.json > /dev/nullpython3 检查只验证 JSON 语法，不验证出口是否在线，也不替代内核配置检查。该文件不能是符号链接。实例若已有公共 kernel.custom_config，新文件会被拒绝而不是静默覆盖；需先整理原有定制配置。
这个文件使用 singbox 原生格式，不能直接用于 Xray。不要修改运行时自动生成的 config.json，也不要在此文件中添加入站或证书设置。
第六步：恢复选中的节点
sudo oo nodes restore --instance INSTANCE_ID --node-id 237 --yes
sudo ss -lntp 'sport = :11449'
sudo journalctl -u oo.service -n 80 --no-pager管理进程会读取覆盖文件并重新启动该子节点。不需要为这一步重启所有实例；其他子节点保持运行。仅保存文件不会可靠地让一个已经运行的节点重新加载，所以每次修改都应先停用该节点、确认停止、再编辑和恢复。
若使用 sudo systemctl restart oo.service，则会重启共享进程，所有 oo 实例会短暂重连。这不是日常修改单节点出口的首选方式。
第七步：验证实际出口，而不只看端口
用支持对应协议的客户端连接新节点。客户端填写的是 AnyTLS 的域名、端口和面板下发的用户密码，不是 SOCKS5 的账号密码。
在确认浏览器流量经过该节点的情况下访问出口 IP 查询网站，并访问实际 HTTPS 网站；出口 IP 应与 SOCKS5 服务商提供的出口一致。再切回原 AnyTLS、Trojan 节点，确认它们仍使用原出口。
服务器直接运行 curl 查看的是服务器自己的出口，不能据此判断子节点是否走了 SOCKS5。服务器直连 Google 成功也不代表客户端 → AnyTLS → SOCKS5 的完整链路成功。
面板的“机器在线”和“节点在线”是不同状态。机器在线不代表所有子节点都启动成功；新节点还需成功拉取用户、上报状态。访问测试后等待一次上报周期再刷新面板，不要仅凭红、黄、绿圆点判断线路是否可用。
分流、DNS 与 UDP 注意事项
route.final 只指定未被其他规则匹配的默认出口。已有面板直连规则或其他出站规则仍然优先。需要该节点的公网代理流量全部走 SOCKS5 时，必须先检查并清理不符合目标的分流规则；不要添加位于私网保护之前的粗暴全匹配规则。
此配置不改变服务器的面板 API、证书申请、其他进程的系统流量，也不保证全部 DNS 查询通过 SOCKS5。普通 SOCKS5 链路本身不提供 TLS 加密，请使用可信的出口服务和网络。
TCP 可用不代表 UDP 可用。UDP 还需要 SOCKS5 服务端支持 UDP 转发并开放相应网络；不要把开关或 UDP over TCP 当成上游自动具备的能力。本教程的 HTTPS 验证仅证明 TCP 链路。
常见问题
端口冲突：新增节点不能使用已有服务的监听端口。面板改好端口后，如节点之前已经启动失败，需要仅停用并恢复该子节点；不应删除其他服务来腾出端口。
JSON 或覆盖配置被拒绝：查看 oo 日志，检查文件位置、权限、JSON 格式、是否误用了 Xray 字段、是否与公共 custom_config 冲突。选中节点应停止，不要为了“变绿”移除专用出口后继续直连。
SOCKS5 连接失败或认证失败：核对地址、端口、账号密码、出口白名单与上游状态。先确认节点服务器能访问上游，再测试完整代理链路。
网站能访问但出口仍是服务器 IP：检查是否升级到支持本功能的版本、文件是否放在正确实例的正确子节点目录、是否完成子节点重启、客户端是否真的使用该节点，以及有无优先匹配的直连规则。
证书错误：检查域名解析、证书有效期、TLS/SNI 和现有续期入口。修改 SOCKS5 出站不需要删除证书或重装 Nginx。
文件在运行期间被移走或破坏：本功能不是持续的防篡改或强制断网保护。已有原生配置加载器在后续重建时可能跳过丢失文件；务必先停用子节点，再编辑或移动文件。备份恢复、回收站恢复后也需重新验证出口。
恢复原出口（仅在确实希望取消 SOCKS5 时）
先停用目标子节点并确认端口停止。把该节点的 kernel.override.json 移到实例外的私有备份目录，然后恢复这个子节点。不要删除整个 node-237 目录、证书或父实例，也不要直接删除 SOCKS5 出站却保留指向它的 route.final。
移走整个单节点覆盖文件后，该节点回到继承的原配置；只有原配置没有其他出站或分流定制时，才等于直连。恢复后重新核对出口 IP，其他节点不应改变。
若配置失败，请让该节点保持停用。不要通过降级到不支持覆盖文件的旧核心来排错，否则该节点可能意外恢复直连。