这篇不是标准教程，更像一次复盘。
我最开始的目标很简单：校园网别老掉，掉了能自己重连。
结果一上双 WAN，直接把我打懵：只要有一个口在线，另一个口看起来也“在线”。日志一片正常，实际上网络已经半瘫。
那几天的状态大概是：
- 抓包时很兴奋，感觉“这不就成了”
- 脚本初版跑起来也很兴奋
- 双口误判后开始怀疑人生
- 最后定位到“出口绑定”和“分口判定”时，才算真正通关
这篇就把这一路的关键点讲清楚，给后来人少踩几个我踩过的坑。
1）起点：先抓包，把登录动作看透
一开始我做的第一件事，就是在浏览器里打开开发者工具抓登录请求。大方向大家都知道，但真正落地的时候，最容易掉进一个坑：
只盯着“是 POST 还是 GET”，却没盯住“真实有效参数”。
我后面确认下来，关键不是请求方法名，而是这些参数要完整、正确：
- 登录地址（
.../eportal/portal/login）
user_accountuser_passwordwlan_user_ip- 终端类型参数（后面讲 mobile / pc）
当时我抓到请求后，第一反应是“好，复制就完事”。
结果当然不是：复制只是开始，可稳定复现才是难点。
2）第一个关键认知：手机登录和电脑登录，不是只改 UA
我一开始真以为换个 User-Agent 就够了。后来发现门户侧没这么“宽容”。
在我这版 campus_login.sh 里，模式切换是三件事联动：
- 账号前缀：
- mobile 用
,1,账号
- pc 用
,0,账号
- 终端类型：
- mobile
terminal_type=2
- pc
terminal_type=1
- 对应 UA
也就是说，必须按“参数组”切换，而不是单变量切换。
这一步跑通之后，我第一次感觉：这个项目从“猜”开始变成“可控”。
3）脚本模拟登录：真正要解决的是“从哪个口发出去”
这个点是我后面双 WAN 能稳定的根。
我在 campus_login.sh 里做了三件事：
A. 按接口读账号
wan 读 LOGIN_ACCOUNT_WAN / LOGIN_PASS_WAN / LOGIN_MODE_WANwan_2 读 LOGIN_ACCOUNT_WAN2 / LOGIN_PASS_WAN2 / LOGIN_MODE_WAN2
这样两个口可以彻底独立。
B. 动态拿接口设备和源 IP
通过 ifstatus 获取：
l3_deviceipv4-address[0].address
不硬编码设备名，不假设 IP。
C. curl --interface 强绑出口
这一条是“救命项”：
curl --interface "$TARGET_DEV" ...
如果不绑出口，系统默认路由会“帮你做选择”，而这个选择在双 WAN 下经常是错的。
4）离线判定：我从“暴力重登”改成“先探测再动作”
我最早也试过简单粗暴：定时直接登录。短期看省事，长期看全是副作用（频率限制、日志噪声、定位困难）。
后面改成现在这套 keepalive.sh 逻辑：
- 逐个接口探测（
wan、wan_2）
- 绑定接口请求探测地址（默认
generate_204）
- 判定三种状态：
online：HTTP 204 或可达portal：出现认证页特征down/unknown：链路或请求异常
- 只有判定为
portal 才发起登录
- 登录后再次探测确认
这套下来，脚本终于不“神经质”了。
5）最折磨人的坑：一个 WAN 在线，两个 WAN 都像在线
这个问题我折腾了很久，真的久。
表面现象：
- 日志看着好像两个都正常
- 实际上某个口已经掉线
- 业务层面表现就是“偶发卡死”“某些流量跑不通”
最后定位根因就两条：
- 探测没严格按接口出口发；
- 登录时没有明确绑定目标接口设备和源 IP。
修完之后我加了几个“分口隔离”设计：
- 每口独立探测：
probe_interface(dev, iface)
- 每口独立认证：
campus_login.sh ... iface dev ip
- 每口独立冷却戳：
/tmp/campus_retry_<iface>.stamp
- 日志明确打接口、设备、IP
到这一步，才真正做到：
掉的是哪个口，就修哪个口；不再“全局误判”。
那一刻的感受很真实：终于不是玄学了。
6）这版脚本我自己最满意的几个点
不是说“完美”，而是实战里确实有价值：
- 分口配置：账号、模式可按接口独立
- 分口探测：不靠默认路由猜状态
- 冷却机制：避免反复触发登录风暴
- 日志裁剪：长跑不至于把系统拖死
它的关键词不是“高级”，而是“可长期维护”。
7）如果让我重来一遍，我会先做这三步
少走弯路版：
- 先把抓包参数归档（别凭记忆改）
- 先做单口稳定，再上双口（不要同时改十件事）
- 所有探测和登录都强制绑定接口（双 WAN 成败关键）
双 WAN 场景最怕“看起来都对”，你得让每一个动作都能回答：
- 我是从哪个口发出去的？
- 我判断的是哪个口的状态？
- 我修复的是哪个口的问题？
这三个问题答清楚了，系统基本就稳了。
8）最后
我现在回看这次折腾，最大的收获不是“写了个脚本”，而是把一个本来很玄学的问题，拆成了可观测、可验证、可恢复的流程。
自动化脚本真正有价值的时刻，不是你第一次跑通它，而是它在你不盯着的时候还能稳定工作。
如果你也在做校园网自动认证，希望这篇能帮你少走几天弯路。