出站只放行 TLS 时，让 Komari Agent 走 HTTP CONNECT 代理的实录

现象
Komari Agent 按官方 install.sh 装好、配置好面板地址与 Token 后，日志里始终连不上，表现为 WebSocket 无法建立。同一台机器上，浏览器经代理可以打开外网页面，说明不是面板地址错了，也不是 Token 错了，而是 Agent 自身的出站路径不通。

定位：先确认出站规则，再怀疑 Agent 配置
1. 先在机器上直接 curl 面板地址，看直连是否通。如果直连被中间层拦截或返回假 IP，Agent 再怎么改配置也不会通。
2. 再用 curl -x http://代理地址 面板地址 验证代理路径是否通。代理通、直连不通，结论就很清楚：问题在出站路径，不在 Agent。
3. 注意沙箱 DNS 的坑：有些环境连 localhost 都会被解析成假地址，代理配置里写 localhost 时要格外小心，必要时用 127.0.0.1。

做法：给 Agent 包一层启动脚本，不要改 Agent 本身
不要去改 Agent 的二进制或配置文件格式。做法是写一个很薄的启动包装脚本：脚本先解析代理地址，优先读运行时的环境变量，读不到再读一份权限 600 的 fallback 文件（里面只放代理地址，不放别的秘密）；然后把代理环境变量传给 Agent 再 exec 启动，这样 Agent 进程里看不到多余的包装逻辑，ps 里也不会暴露 Token。配置文件保持 JSON 格式、权限 600，endpoint 与 Token 只写在配置文件里，不写进启动命令，也不写进 systemd 的命令行。systemd 的 ExecStart 指向包装脚本而不是 Agent 二进制，这样服务重启、机器重启后路径一致，不会某次手动启动走了直连、某次服务启动走了代理，造成时好时坏。

验证标准
只看一条就够了：日志里出现 WebSocket connected 一类的已连接提示，并且面板侧能看到该节点在线。不要只看进程在跑——进程在跑但连不上，等于没跑。

容易复发的两个点
1. 代理凭据会轮换：fallback 文件里的旧凭据不要覆盖运行时的新凭据，脚本的读取顺序必须是“运行时环境优先，fallback 兜底”，否则某天凭据一换，Agent 就悄悄断线。
2. 恢复脚本要同步：机器重置后只恢复 Agent 二进制是不够的，启动包装脚本、systemd 单元、配置文件要一起恢复，否则恢复完还是直连老路。

结论
出站受限的环境里，先分清“直连不通”还是“Agent 配错”，再用一层薄启动脚本把代理路径固定下来，比反复重装 Agent、反复换面板地址要快。关键是让代理路径成为服务定义的一部分，而不是某次手动启动时的临时环境变量。