架构说明（A/B/C 模型）

本系统采用 纯转发模式，中转端 B转发所有请求，C 的 IP 对 A完全透明不暴露。

C（服务端）心跳 → B（中转端）

C 每5秒向 B 发送心跳请求，B 自动记录 C 的来源 IP。

心跳只需带上 绑定名称，不需要规则单词。同一绑定下的所有规则共享同一个 IP：

# 例：绑定 app1（C 向 B 发送心跳）
curl -X POST http://B的IP:8113/api/relay/heartbeat/app1

# Python 示例（C 端运行）
import requests, time
while True:
    r = requests.post("http://B的IP:8113/api/relay/heartbeat/app1")
    print(r.json())
    time.sleep(5)

A（客户端）转发请求 → B（中转端）

A 向 B 发送请求，B 自动转发到 C 的对应端口，C 的 IP对 A 完全透明：

# A 向 B 发送请求，B 转发到 C（A 端运行）
import requests

# 例：绑定 app1，规则 game1，请求 /download/file.zip
r = requests.get("http://B的IP:8113/api/relay/proxy/app1/game1/download/file.zip")
print(r.text)

# POST 请求同样支持
# r = requests.post("http://B的IP:8113/api/relay/proxy/app1/game1/api/data",
#     json={"key": "value"})

流量说明

• • A → B → C：A 的所有请求都经过 B 转发到 C，C 的响应也经 B 返回给 A
• • C → B：每5秒一次心跳包（极小流量）
• • C 的 IP 完全隐藏：A 不知道 C 的真实 IP，只能通过 B 中转
• • B（中转端）需要处理所有数据流量，请确保带宽充足

注意事项

• • C 的 IP 变化后，最多等待5秒（心跳间隔）B 即可自动更新转发目标
• • 如果 C 超过30秒未发送心跳，B 会标记为离线，转发会返回 502
• • 心跳接口和转发接口无需认证，请勿对外公开 B 的中转地址
• • 建议 C 使用 systemd 或 supervisor 守护心跳进程