MHSanaei3x-ui 核心维护者

作者发言

GitHub·2026.10.03 07:32:35（UTC+8）

MHSanaei：3x-ui 面板已用 Panel Outbound 覆盖 Telegram 机器人走隧道，仅机器人单独走代理不值得再加一条桥接

MHSanaei 在 3x-ui PR #6682（为 Telegram 机器人流量新增可选路由入站标签）下说明关闭该 PR 的理由。他指出面板已经覆盖这一需求：在「设置 → 常规 → 面板出站（Panel Outbound）」中选择一个出站或负载均衡器（例如 warp）后，面板会注入一条仅回环的 SOCKS 桥接（panel-egress）并带有自己的路由规则；未单独设置机器人代理时，Telegram 机器人会经该桥接拨出。在 Telegram 被过滤的主机上，只需在此处选择隧道出站即可。他认为该 PR 唯一多出的是「只路由机器人、不影响面板其他出站流量」，这需要第二条并行桥接和一个必须在两处保持同步的魔法入站标签，他不认为为收窄范围值得付出这个代价。同时他确认对方指出了一个真实缺陷：机器人只在启动时读取一次出站桥接，如果 Xray 稍后才启动，或 Panel Outbound 发生变化，机器人会一直直连直到重启；这将在现有的 panel-egress 路径上单独修复。

作者原文@MHSanaei

Thanks for the PR and for the clear write-up.

Closing this because the panel already covers this: Settings → General → Panel Outbound. If you pick an outbound or a balancer there (e.g. warp), the panel injects a loopback SOCKS bridge (panel-egress) with its own routing rule. The Telegram bot dials through that bridge when no dedicated bot proxy is set. On a host where Telegram is filtered, choosing your tunnel outbound there is enough.

The only extra thing this PR offers is routing just the bot and not the panel's other egress traffic. That would mean a second, parallel bridge with a magic inbound tag that has to stay in sync in two places, and I don't think the narrower scope is worth that.

You did spot a real gap, though. The bot reads the egress bridge only once, at startup. If Xray comes up later, or Panel Outbound changes, the bot keeps connecting directly until it restarts. That will be fixed separately on the existing panel-egress path.