[Feature request]: 前置代理支持多节点自动切换 #7642
Description
相关问题
- 当我使用节点A的时候，设置了节点1作为节点A的前置代理；
- 可能会遇到的情况是，当作为前置代理的节点1失效后，就会导致整个连接链的中断；
- 因此，是否能支持设置多个前置代理节点，例如允许添加节点1、节点2、节点3，3个已经足够了，不需要特别多；
- 之后，引入一个自动检测机制，例如每隔一段时间检查节点1的连通状态，如果节点1是断开的，那么自动切换为节点2作为节点A的前置代理；
===================================================================================
When I use node A, I set node 1 as node A’s upstream proxy.
A possible issue is that if the upstream proxy node 1 fails, the entire connection chain will be interrupted.
Therefore, is it possible to support setting multiple upstream proxy nodes? For example, allowing nodes 1, 2, and 3 to be added—three nodes should be enough; no need for too many.
After that, introduce an automatic detection mechanism that checks node 1’s connectivity status at regular intervals. If node 1 is disconnected, it would automatically switch to node 2 as node A’s upstream proxy.
描述你希望的解决方案
但是，这个自动检测机制我没想好还，因为如果设置每5秒检测一次，会导致前置代理节点发送请求太过频繁，可能会导致连接的检测服务器认为前置代理节点是恶意的，导致前置代理节点被对应检测服务器封杀ip；
初步的想法就是有两种，主动检测与被动检测，或者主动+被动
方案一：主动式检查
可能的解决途径就是选择合适的检测目标（URL）： 不要检测 www.google.com 或 www.baidu.com 这种大型商业网站。使用专门用于连通性测试的、轻量级的、不会有复杂的风控策略的URL，例如：
http://cp.cloudflare.com/generate_204http://www.gstatic.com/generate_204http://detectportal.firefox.com/success.txt
- 设置合理的超时（Timeout）： 检测请求设置一个较短的超时时间，比如3-5秒。如果在这个时间内没有收到响应，就可以认为节点可能存在问题。
- 引入“失败阈值”： 不要因为一次检测失败就立刻判定节点失效。可以设置一个阈值，例如“连续3次检测失败，才将节点标记为不可用”。这样可以有效防止因网络瞬间抖动造成的误判。
方案二：被动式检查
核心思想： 平时不检测，出错时再切换。
工作流程如下：
- 正常工作： 系统默认使用节点1作为前置代理。所有来自节点A的请求都通过节点1转发。
- 检测失败： 当节点A通过节点1发起一个真实连接时（比如打开一个网页），如果这个连接失败了（例如TCP连接超时、握手失败等），V2rayN捕捉到这个失败事件。
- 立即切换： 在捕捉到失败后，立即将节点1标记为“暂时不可用”（并为其设置一个“冷却时间”，例如5分钟），然后自动使用节点2来重试刚才失败的那个连接。对于上层应用（比如浏览器）来说，它只是感觉第一次连接慢了一点（因为要等待节点1超时），但请求最终成功了，整个过程是自动且无感知的。
- 自动恢复： 在节点1的“冷却时间”（比如5分钟）过后，系统会将其重新放回可用列表。下次有新的连接请求时，可以再次尝试使用节点1。如果它依然失败，就再次进入冷却；如果成功，它就恢复正常工作。
方案三：主动+被动策略
-
主要机制 - 被动检测：
- 日常连接使用被动检测机制。当主节点（节点1）在处理真实请求时失败，立即切换到备用节点（节点2），并对节点1进行短暂“惩罚”（例如5分钟内不使用）。
-
辅助机制 - 主动检测：
- 系统在后台运行一个低频率的、优化的主动检测任务（例如每10分钟一次）。
- 探测恢复： 检查那些被“惩罚”的节点是否已经恢复正常。如果恢复了，就将其移出“惩罚”列表。
- 择优选择： 不仅仅是检查“通/不通”，还可以测量所有可用节点（节点1, 2, 3）的延迟（Latency）。然后自动选择延迟最低的那个节点作为当前的主节点。
- 系统在后台运行一个低频率的、优化的主动检测任务（例如每10分钟一次）。
===================================================================================
However, I haven’t finalized the automatic detection mechanism yet, because if detection occurs every 5 seconds, the front proxy node will send requests too frequently, which might cause the detection server to perceive the front proxy node as malicious and block its IP.
The initial ideas fall into two categories: active detection and passive detection, or a combination of both.
Plan One: Active Checking
A possible solution is to choose appropriate detection targets (URLs): avoid checking large commercial websites like www.google.com or www.baidu.com. Instead, use URLs specifically designed for connectivity testing—lightweight and without complex security policies—such as:
http://cp.cloudflare.com/generate_204http://www.gstatic.com/generate_204http://detectportal.firefox.com/success.txt
- Set a reasonable timeout: Configure detection requests with a short timeout, for example, 3–5 seconds. If no response arrives within this time, the node may be considered problematic.
- Introduce a "failure threshold": Don’t mark a node as invalid after just one failed check. For example, set a threshold like "mark the node unavailable only after 3 consecutive failures." This effectively prevents false positives caused by transient network glitches.
Plan Two: Passive Checking
Core idea: Do not check regularly; switch only when a failure occurs.
Workflow:
- Normal operation: The system defaults to using node 1 as the front proxy. All requests from node A are routed through node 1.
- Failure detection: When node A makes a real connection through node 1 (like opening a webpage), if the connection fails (e.g., TCP timeout, handshake failure), V2rayN captures this failure event.
- Immediate switch: Upon catching the failure, node 1 is immediately marked as “temporarily unavailable” (with a “cooldown period,” for example, 5 minutes), and node 2 is automatically used to retry the failed connection.
- Seamless experience: For the applications on top (like a browser), the only noticeable effect is a slightly slower first connection (waiting for node 1’s timeout), but the request ultimately succeeds, and the entire process is automatic and transparent.
- Automatic recovery: After node 1’s cooldown period (for example, 5 minutes) expires, the system returns it to the available list. The next time a connection attempt occurs, it will try node 1 again. If it fails again, it re-enters cooldown; if it succeeds, it resumes normal operation.
Plan Three: Active + Passive Strategy
- Primary mechanism – passive detection:
- Use passive detection for everyday connections. When the primary node (node 1) fails during a real request, switch immediately to the backup node (node 2) and apply a short “penalty” to node 1 (e.g., avoid using it for 5 minutes).
- This ensures instant response to failures and uninterrupted connections.
- Secondary mechanism – active detection:
- Run a low-frequency, optimized active detection task in the background (for example, once every 10 minutes).
- The purposes of this task are:
- Recovery probe: Check if nodes under “penalty” have recovered; if so, remove them from the penalty list.
- Optimal selection: Beyond simple reachability checks, measure the latency of all available nodes (nodes 1, 2, 3) and then automatically select the node with the lowest latency as the current primary node.
描述你所考虑的替代方案
No response
我确认已查询历史issues
- 是