AutoForward Hub （机场+TOK直播-助手）转发面板win第12-58个版本
转发面板功能更新迭代介绍
| AutoForward Hub | 功能名称 | 功能详情 |
|---|---|---|
| 1 | 多服务器管理 | 支持多服务器管理，一键安装中转面板；给服务器端安装面板，LX面板和Win面板二合一，Win面板启动规则后离线，LX服务器可同步运行 |
| 2 | 邮箱检测警示 | 支持邮箱检测，可检测IP被墙、服务器异常、服务器关机，检测到异常直接发送邮件警示 |
| 3 | 转发管理功能 | 支持添加转发、批量转发，可一键开启、一键更换端口，支持离线转发 |
| 4 | 流量监控功能 | 新增流量监控功能，可查看上传、下传实时速度，以及总上传、下传用量 |
| 5 | SSH终端功能 | 支持SSH终端功能，无需连接额外SSH工具，可直接使用终端命令快捷操作，提供常用快捷命令 |
| 6 | FTP文件管理器 | 新增FTP文件管理器，可上传、下传文件，支持下载，保留目录路径复制功能，方便终端调用路径 |
| 7 | 终端日志监控 | 支持终端日志监控，可实现一目千行查看，日志窗口可最小化使用、单独使用窗口、单独会话 |
| 8 | 桌面在线预警 | 支持桌面在线预警，出现异常时可弹窗提醒 |
| 9 | 预期功能-V2协议脚本一键安装 | 预期添加V2协议脚本一键安装功能，支持可视化编辑，可实现启动、暂停操作 |
| 10 | 解析安全助手 | 实现CF自己切换DNS解析IP的能力，实现自动化切换IP和域名 |
| 11 | 轮询黑名单（安全屋） | 流量阈值一过-达到临界值把可能超时的IP送去黑名单进行休眠-等风头过了-尝试在黑名单连接进行自愈，如果成功连通，自己提出黑名单。进行投入轮询使用。进行完美闭环 |
功能介绍
1,支持多服务器管理 一键安装中转面板 给服务器端安装面板 lx面板 和win面板二合一 win面板启动规则后 ，win面板离线。lx 服务器可以同步运行
2,支持邮箱检测，检测IP被墙，服务器异常，服务器关机，直接发邮件警示
3，支持添加转发-批量转发-一键开启-一键更换端口-离线转发
4.增加流量监控功能-上传下传实时速度-和总上传下传用量
5.支持ssh终端功能不需要连接额外的ssh 工具可以使用终端命令快捷操作（提供快捷常用）
6.增加FTP文件管理器，可上传下传文件，支持下载，保留目录路径复制功能（方便终端路径）
7.终端日志监控-监控一目千行-可以最小化使用，可以单独使用窗口，可以单独会话
8,桌面在线预警 弹窗预警
9.预期添加V2协议脚本一键安装功能（可视化编辑）启动暂停。
10，预期添加机场自己更换端口功能实现-自动化-自己探测异常更换功能。（直连利器）
系统配置要求
客户端配置（Windows 专用）
| 配置项 | 最低要求 | 推荐配置 |
|---|---|---|
| CPU | 4 核 | 6 核 + |
| 内存 | 4GB | 8GB+ |
| 磁盘 | 5GB | 20GB+ |
| 系统 | Windows 7/8/10/11 | Linux 不支持 |
服务端配置（Linux 专用）
| 配置项 | 最低要求 | 推荐配置 |
|---|---|---|
| CPU | 1 核 | 2 核 + |
| 内存 | 512MB | 2GB+ |
| 磁盘 | 5GB | 20GB+ |
| 系统 | Linux（Debian 11） | Windows 不支持 |
支持异端口同步功能 随机添加一条规则，但是目标地址一致，监听信息会随机端口(方便复制端口哦)
添加规则自动创建转发。
邮箱监控，我走的是QQ邮箱协议，方便管理和申请，可以检测目标端口和监听端口的运行情况 如果出现异常 被墙亦或者服务器挂掉 都会进行邮箱提示。
邮件通知。
系统优化脚本安装
出现 bash: line 1: unzip: command not found 报错
需要安装解压工具
unzip 解压工具
sudo apt-get update && sudo apt-get install -y unzip
遇到报错可执行
步骤1
cat > /etc/apt/sources.list << EOF
deb https://mirrors.aliyun.com/debian/ bullseye main non-free contrib
deb-src https://mirrors.aliyun.com/debian/ bullseye main non-free contrib
deb https://mirrors.aliyun.com/debian-security/ bullseye-security main
deb-src https://mirrors.aliyun.com/debian-security/ bullseye-security main
deb https://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib
deb-src https://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib
EOF步骤 2
apt-get update && apt-get install -y unzip新增域名绑定 服务器主绑定域名 所有解析跟着域名转发
进阶域名无感修复节点
复制不变规则 指的是复制目标服务器全体规则的时候 监听地址会跟随目标地址而变化 端口不变 目标和目标端口也没有变化
17个版本 SSH终端显示放在前面用到比较少 日志比较多 所以放在首页
需要监听查看
解析智能守护
功能特性：
- 健康检测 – 定时检测主服务器端口（默认 38.190.245.62:53020）是否连通
- 故障判定 – 连续 N 次失败后判定离线（默认 3 次）
- 转发切换 – 自动把所有转发规则的目标 IP 切换到备用服务器
- DNS 切换 – 调用 Cloudflare API 自动修改域名解析 IP
- 恢复切回 – 主服务器恢复后自动切回 + 恢复 DNS 解析
- 独立日志 – 有专属的守护日志窗口，可查看/清空/导出
使用方法：
- 打开工具箱 → 点击「🛡️ 解析守护助手」
- 填写配置：
- 主/备用服务器 IP 和端口
- 检测间隔和失败阈值
- Cloudflare API Token、Zone ID、域名
- 点击「💾 保存配置」
- 点击「▶ 启动守护」
日志查看：
- 随时点击「📋 查看守护日志」查看完整的切换记录
- 支持导出为 txt 文件
解析守护助手（目前最省心的功能，自己实现容灾切换）
密钥获取 接口位置我放在
目前解析守护助手 我添加了ABCD备用服务器环境 A服务器损坏死机 B服务器会自己替换解析CF域名自己更换IP实现自动化操作。
静默三次 如果出现网络超时亦或者公网波动不会触发自动切换场景
AutoForward Hub内核是我自研发的YYZQ内核面板
是我用纯 Python实现的转发内核。
1.直接使用 Python socket库-代码使用原生 socket模块创建监听和连接
2.多线程架构-使用 threading.Thread 处理每个连接
3.支持的协议
TCP普通转发
·UDP转发
TLS/TLS13加密转发
WebSocket/WSS 伪装转发
4.核心函数:
tcpforward() / tcp_forward_thread()
TCP转发
udp_forward() / udp_forward_thread()UDP 转发
使用 select.select()实现I/O多路复用
这是YY ZQ转发面板自研的 Python 内核，不依赖socat、iptables 或任何外部转发工具，纯 Python 代码实现的流量转发功能
后来为了配合 AutoForward Hub 面板实现功能 目前就叫做 AutoForward Hub内核前名是YYZQ转发面板
绑定域名是可以直接绑定该服务器 让该服务器直接实现全部规则转发，不用对单独的规则进行多余的配置
域名转移顾名思义，域名可以继承给B使用
复制转发规则 我采用的是 只复制监听的端口和目标地址和端口，复制到B服务器自己实现监听地址因为B服务器的IP而变化 实现快捷复制功能。很省心
异口同步是简称 其实就是异端口同步 可以实现监听端口随机复制 当前规则 ，但是只有监听端口有变化，实现多复制，堆山模式。
安装内核 这个内核就是之前说的 不过这个内核我放在我的服务器上进行获取下载到客户端服务器上 实现云端对云端下载进行安装，本地上传是我留了一手，防止云端失效。不过初次 我设置的本地密码。暂不提供，因为还在内测期间
修复 修复功能就是巡检功能，检查当前服务器端口和目标服务器有没有脱离，或者其他异常，这是主动检测，不过AutoForward Hub的建设已经实现了 自主检测并且发送邮箱的预警，这个功能可以主动检测。
常用场景简单工具箱
日志心脏大屏 ，监控日志使用，不过里面最多的是目标端口和监听服务器的对接规则 可以实现5秒检测观看是否异常的场景。不过解析守护助手不走这里。
解析守护助手日志比较特殊我给分开运行展示了。
SSH 终端 这个并不少见，我给AutoForward Hub 面板带在了内置的SSH面板 可以输入常用命令进行审查，或者安装其他依赖 以及环境。
给ssh 的旁边搭建了 文件管理器 方便一边输入命令一边上传下载使用。包括脚本安装之类的进行调试
路径我特意开发的时候 让他具有可复制性，可以直接复制路径cd 到你任何想去的地方。
运行日志 不用担心这个日志占用电脑空间硬盘，这个日志我写进了内存里面，限制500条超出自己清理，每次重启都是一次崭新的 不用担心 占用多余的空间
增加 定时切换功能 指定时间可以自己切换 ABCD 服务器 一直循环
增加 一键IP入库功能 不用单独取服务器列表创建服务器进行创建增加服务器繁琐操作
一键IP入库，直接入库解析助手服务器IP库-
黑名单功能 黑名单管理，指的是 解析安全助手触发不论是流量阈值还是守护故障自动切换-如果此IP服务器被墙了 自动入库黑名单，然后下次循环时-不再利用已经故障的服务器，减少时间成本-错误成本-消耗成本-以及最重要的导致客户端浪费最起码20分钟来循环修复。
包括新增的 流量切换也是一样的 达到自己的阈值之后，会主动切换。
目测已经挺过了很多的高峰期，比如是21点之后防火墙的管控区
目前对抗GFW测试一天，不错的对抗，具体还要等时间。测试为准
在HCKJ家的大宽带服务器-500G的限制流量，在之前没有设置3GB阈值自己没有切换的功能之前
在用户使用10G-或者30GB的时候直接被墙了。现在设置的是3GB阈值，突破后自己切换已经突破至185GB
[2026-04-22 08:25:51] 📊 A 流量达 3.01 GB，触发切换
[2026-04-22 08:25:51] 🚨 切换到服务器 B: 156.246.89.82:22
[2026-04-22 08:25:51] 使用 Global API Key 模式
[2026-04-22 08:25:52] ✅ DNS已切换到服务器 B: 156.246.89.82
[2026-04-22 08:52:51] 📊 B 流量达 3.09 GB，触发切换
[2026-04-22 08:52:51] 🚨 切换到服务器 C: 45.196.97.189:22
[2026-04-22 08:52:51] 使用 Global API Key 模式
[2026-04-22 08:52:52] ✅ DNS已切换到服务器 C: 45.196.97.189
[2026-04-22 09:12:32] ❌ 服务器 C 离线 (第 1/4 次)
[2026-04-22 09:13:42] ❌ 服务器 C 离线 (第 2/4 次)
[2026-04-22 09:15:27] ❌ 服务器 C 离线 (第 3/4 次)
[2026-04-22 09:19:51] 📊 C 流量达 3.06 GB，触发切换
[2026-04-22 09:19:51] 🚨 切换到服务器 D: 156.246.95.11:22
[2026-04-22 09:19:51] 使用 Global API Key 模式
[2026-04-22 09:19:52] ✅ DNS已切换到服务器 D: 156.246.95.11
[2026-04-22 09:45:51] 📊 D 流量达 3.12 GB，触发切换
[2026-04-22 09:45:51] 🚨 切换到服务器 E服务器-HENGCHUANG: 149.30.222.105:22
[2026-04-22 09:45:51] 使用 Global API Key 模式
[2026-04-22 09:45:52] ✅ DNS已切换到服务器 E服务器-HENGCHUANG: 149.30.222.105
[2026-04-22 10:12:51] 📊 E服务器-HENGCHUANG 流量达 3.11 GB，触发切换日志所示
ABCDE切换的很流畅-
[2026-04-22 09:12:32] ❌ 服务器 C 离线 (第 1/4 次)
[2026-04-22 09:13:42] ❌ 服务器 C 离线 (第 2/4 次)
[2026-04-22 09:15:27] ❌ 服务器 C 离线 (第 3/4 次)
但是其中出发了一次警报这个警报可能跟公网波动问题导致
如果是之前的3/3次检查服务器的健康性-已经错误切换了
目测4/4的检测次数是效果最佳的，但是缺点用户体验一般
带来错误判断效果恢复时间稍长。目前测试时间
| 日期 | 状态说明 |
|---|---|
| 4 月 20 日 | 未被墙，22 点之后正常 |
| 4 月 21 日 | 20 点端口被墙，数量：2 个-但是要注意的是，只是墙了端口-不是特别大的问题 常规IP节点和轮换域名节点 同时发生这个问题。从原本的ABC三台服务器 我增加了 ABCDE又加两台服务器进行测试，叠加服务器-也就意味着 每次循环一次- 如果按照大约3GB 25分钟的计算 5台服务器的循环将是100分钟 也就是 一小时40分钟，这给足了服务器冷却健康恢复时间。 -但是正真要注意的是-关于之前端口被墙的问题，貌似我更换了多台服务器，只要是纯IP依然无法解决，台湾这一台机器的节点问题，只要换上域名 就立马能用了 -很奇怪 需要观察-不过值得庆幸的是 AutoForward Hub 的可使用率-可达率-高达百分之九十五，包括稳定性也是，这种脚本运行的稳定率比AI更靠谱更稳定。 |
| 4月22日 | 特殊IP端口 死亡被墙-这个是正常的因为没有运用自己更换技术 没有做循环流量临界值 |
| 4月23日 | 循环的五台机器中-有一台已经阵亡目测已经被墙-来自AK家的-日本服务器-不过运气不错的是 HCKJ之前挺过了185GB 现在已经正常到达227GB 目测未被墙。 |
| 4月24日 | 常规IP机器 端口被封。更换之后 进行恢复-目前用的是模拟3GB流量进行切换 227GB HCKJ 已经达到 264GB 相比而言已经增加了 37GB的量 如果这个量跑到500GB 安然无恙说明没有什么太大的问题。 我今天进行实测，黑名单功能具有检测预热要被墙的IP服务器，然后肯定有超时的情况，当超时超过一定的时候，黑名单的误判-极有可能是歪打正着-让可能预热被墙的IP服务器-拉入黑名单-实则黑名单（像极安全屋） |
| 4月25日 | 不知道 是什么原因 纯IP模式 目前只走端口模式 但是存活概率也会有效提升。不知道是人员的减少，还是其他的可能性，可能都迁移在自动修复节点身上，而纯节点的本身没有进行太多的关注、只是轻微影响到端口。政策放宽也可能是其中之一。 |
| 4月26日 | 端口未被墙-包括IP也是-偶尔几个加入黑名单 但是一切正常-轮询有效 |
| 4月27日 | HCKJ 正常跑到了 397G 快越过400G大关 目前跑到了 418GB 但是目前域名 端口 台湾和香港陆续挂掉 只是挂掉端口 |
57个版本更改 UI画面
黑名单轮询自愈+自己尝试连接-不占用浪费资源（待改进）
+黑名单自动过期时间
比如超时进黑名单，静默冷却 30 分钟 / 1 小时，自动移出重回轮询。既不让带病节点继续坑用户，又把节点养着不被彻底封，完美闭环。
既不让带病节点继续坑用户，又把节点养着不被彻底封，完美闭环。
流量监控升级拓展
从单一统计数据改成每台数据流量分流观看
整体页面
