校园网认证这件事说小很小说烦是真烦。每天打开电脑浏览器弹出一个认证页面输入账号密码点登录一天掉线三五次每次都得重来一遍。如果手上还有一台常年开着的开发机、一台树莓派、几台虚拟机那这套动作一天要重复十几次。这篇内容就是把“手动点登录”这件事彻底自动化掉——核心手段就是用 POST 请求复现认证流程让脚本代替人去填表、提交、并在掉线后自动重连。关键词很明确校园网、POST 自动认证、断线重连、守护进程。它解决的不是什么高深问题而是“高频、低价值、必须人肉介入”的重复劳动。适合三类人看一是宿舍里被认证页面折磨到崩溃的普通用户照着步骤能跑起来就行二是想借这个场景练手的初学者Portal 认证是一个极好的 HTTP 抓包与协议还原练习比看教程敲一遍“爬虫入门”有用得多三是已经在做运维、嵌入式、自动化相关工作的朋友里面关于守护进程、日志脱敏、开机自启那几段可以直接搬走用。下面我按“搞懂它怎么运作 → 抓出关键参数 → 写出可跑的脚本 → 让它稳定活下来 → 出问题怎么查”这条线把整个过程摊开讲。1. 先把认证流程拆明白再动手1.1 一次手动登录背后到底发生了什么很多人一上来就去抓包抓完发现一堆参数看不懂卡在这里就放弃了。我的建议是先别急着开工具先在脑子里建立一个模型你点“登录”的那一瞬间浏览器至少完成了三件事——获取认证入口地址、拼装表单参数、向网关提交并接收结果。这三件事对应三段不同的网络行为抓包时要把它们分清楚否则会把“跳转”当成“提交”把“页面渲染”当成“接口返回”。具体来说连上校园 Wi-Fi 或网线后你的设备拿到一个内网地址。此时访问任何外部站点网关并不会直接放行而是把你的请求拦下来返回一个重定向把你引导到认证服务器上的一个页面。这个页面的地址里通常带着一串查询参数比如你的终端 IP、接入设备的标识、原始访问的目标地址等等。这些参数就是后续提交时要用到的“上下文”丢一个都可能导致认证失败。这就是为什么很多人直接抄别人的脚本跑不通——别人的 IP 和你不一样接入设备标识也不一样。认证页面加载完之后里面嵌着一个表单表单的提交地址往往和页面地址不是同一个域名或路径。你填账号密码点提交浏览器把表单数据以 POST 形式发到这个地址网关校验通过后返回一段结果可能是 JSON也可能是跳转到一个成功提示页同时在你这个 IP 上打一个“已认证”的标记之后你的流量才被放行。理解了这个“先重定向、再提交、后放行”的三段式结构抓包时你就知道该盯哪几个请求了。这里有个很容易被忽略的点认证状态是绑定在 IP有时还叠加 MAC上的不是绑定在你的设备身份上。这意味着两件事。第一你换一个 IP比如从 Wi-Fi 切到有线、或者 DHCP 重新分配就需要重新认证一次。第二如果同一网段里有人手动填了和你一样的 IP 配置会导致双方都认证不上或者互相踢下线这是宿舍里常见的“玄学掉线”原因之一。知道这一点后面写断线检测逻辑时你就明白光判断“网络通不通”是不够的得判断“我这个 IP 的认证标记还在不在”。1.2 三条技术路线为什么最后选了模拟 POST自动化认证这件事业内有三种常见做法各有各的适用场景我在不同阶段都用过这里做个横向对比方便你按自己的情况选。路线实现方式资源占用稳定性维护成本适用情况模拟 POST 请求用 HTTP 客户端直接提交表单极低几 MB 内存高但惧怕接口变更中接口变了要重抓绝大多数场景首选浏览器自动化无头浏览器加载页面并点击高几百 MB中页面改版即失效高页面有复杂 JS 加密或验证码图形界面模拟模拟鼠标键盘点击中低窗口焦点一变就崩高实在没办法时的兜底第一种是首选因为它最轻、最快、最容易做成后台常驻。缺点也很直白一旦认证页面改版、参数增减、加密方式变化脚本立刻失效需要重新抓包调整。第二种的好处是“所见即所得”页面上人怎么点脚本就怎么点对 JS 加密、动态渲染的兼容性好得多代价是资源占用高跑在宿舍那台常年开机的旧笔记本上还行跑在树莓派上就有点吃力而且无头浏览器在很多环境里会因为缺少图形依赖而启动失败。第三种我是真不推荐除非前两条路都走死了。它的脆弱程度超出想象系统弹个通知、分辨率变一下、输入法切一下坐标就全偏了。而且它必须依赖一个可见的桌面会话远程或者无人值守时完全没法用。我最终落在第一条路上还有一个很实际的原因校园网认证接口通常极其简陋。它不需要考虑多终端适配、不需要考虑无障碍、不会有复杂的风控所以前端那点加密手段往往就是一层简单的哈希看一眼 JS 就能还原。投入产出比高得离谱。反过来说如果你抓包后发现密码字段是一长串看不懂的密文且 JS 被严重混淆那再考虑退到第二条路。注意这套自动化的前提是使用你自己的账号、你自己名下的终端设备。把自己的账号密码交给脚本去跑本质上和你在浏览器里手动输入没有区别但请不要把脚本分享给他人共用账号也不要把凭据硬编码后推到公开仓库这是最容易被忽略的安全问题。1.3 方案的整体骨架长什么样在正式动手前先把最终形态想清楚避免写到一半推翻重来。我的脚本整体是四层结构参数采集层负责在未认证状态下捕获重定向拿到 IP、接入设备标识等上下文认证执行层负责拼装表单并提交解析返回结果状态检测层负责周期性判断当前是否在线守护调度层负责串联前三层处理异常、记录日志、控制重试节奏。分层的好处是每一层都能独立调试。新手最容易犯的错是把所有逻辑塞进一个大函数里一旦失败根本不知道是参数取错了、提交格式错了、还是判断在线状态的逻辑本身有 bug。分成四层之后你可以单独测“参数采集”打印出来和人家的成功请求对比也可以单独测“状态检测”手动断网看它能不能正确识别。这种可拆解性在排查问题时价值极大。另外提前说清楚一个设计取舍认证和检测要共用同一个会话对象。有些网关会在认证成功后下发 Cookie后续的状态检测如果用一个全新的会话来发请求可能被当成未认证的新客户端从而误判掉线触发无意义的重连。共用会话还能复用底层的 TCP 连接减少握手开销在检测频率较高时比如每 10 秒一次这个差别是能感知到的。2. 抓包还原把认证参数一个一个抠出来2.1 抓包前的环境准备工欲善其事。抓包这一步我建议在电脑上做不要在手机或开发板上做因为你需要看完整的请求头、请求体、响应头和响应体。浏览器自带的开发者工具就够了不需要额外装软件。打开方式是按 F12 或者右键检查切到“网络”面板勾上“保留日志”和“停用缓存”两个选项——这两个勾非常关键不勾的话页面一跳转之前的请求记录就全被清空了你会对着空白面板怀疑人生。准备工作还有一个容易被忽略的细节先把当前认证状态清掉。如果你现在是已认证状态访问任何网站都直接通根本不会触发重定向自然抓不到认证流程。正确做法是找到认证页面主动点一次“注销/下线”或者干脆等它自然超时。有些网关的注销入口藏得很深可以先访问认证服务器的根路径试试。然后清空网络面板的记录点一次注销再随便访问一个外部站点看着页面被重定向到认证页这时候网络面板里就会出现完整的一串请求。整个过程保持面板打开不要刷新页面。我第一次做的时候就是因为中途刷新了一下日志清空白忙活二十分钟。工具方面浏览器开发者工具适合看单次请求的细节如果你需要看多次重连之间的差异、或者想批量比对参数变化那就需要一个能保存请求记录的工具比如把请求导出成 HAR 文件或者用命令行工具把请求完整打印出来。我在调参阶段习惯把每次请求的完整 URL 和请求体写进一个日志文件方便事后 grep 对比这个习惯帮我定位过好几次“某个字段悄悄变了”的问题。2.2 从重定向里提取上下文参数第一段要抓的是重定向。你在未认证状态下访问一个外部地址比如某个常见的公共 DNS 探测页网关会返回一个 302响应头里的 Location 字段就是认证页面的完整地址。这个地址长这样参数名做了抽象处理http://认证服务器地址/portal页面?userip10.x.x.xwlanacnameAC-XXXnasip10.x.x.xwlanparameterxxxxurlhttp://你原本要访问的地址这里面的每一个参数都不是摆设。userip是你的终端在校园网内网里的地址网关靠它定位“给谁放行”wlanacname和nasip标识你连的是哪个接入设备多校区、多楼栋的校园网里这个值千差万别硬编码必挂wlanparameter通常是加密过的会话标识有时效性隔一段时间就失效不能缓存复用。我的做法是不硬编码任何一个参数而是每次认证前先主动发一次请求故意让它被重定向然后从 302 响应里用正则把这几个参数抽出来。这样即使换了楼栋、换了设备、IP 变了脚本也能自适应。这一步是整个方案健壮性的基石比后面写多漂亮的代码都重要。具体实现上有个坑Python 的 requests 默认会自动跟随重定向你拿到的就是最终页面看不到中间的 302。所以要么在请求时把allow_redirects设为False手动读headers[Location]要么关闭自动重定向后自己决定下一步。我一开始就是被这个默认行为坑了打印出来全是 HTML找不到 Location 头还以为是网关不返回重定向。提示如果你发现访问外部地址时根本没有 302而是直接返回了一个认证页面的 HTML说明这个网关用的是另一种拦截方式返回 200 但内容是认证页。这时候就从 HTML 里用正则提取参数思路是一样的只是提取源从响应头变成了响应体。2.3 表单提交接口与字段含义第二段要抓的是真正的提交请求。在认证页面上填好账号密码点登录网络面板里会多出一条 POST 请求。这条请求有几个必须记录下来的信息请求 URL提交的目标地址通常和页面地址不同、Content-Type多半是表单编码少数是 JSON、请求体的完整字段列表、以及响应体的格式。请求体里的字段可以分成三类理解分类能帮你在接口变更时快速定位问题。第一类是身份类账号、密码或者密码的哈希。第二类是位置类终端 IP、接入设备标识、接入设备 IP这些基本都来自上一步提取的上下文是动态的。第三类是装饰类加密方式标记、客户端类型、版本号、时间戳、随机数、回调函数名等等这些字段看着没意义但缺一个就可能被拒绝必须原样带上。我见过有人为了“精简”请求把看起来没用的字段一个个删掉试最后发现某个叫jsVersion的字段是必须的。这种逆向式的精简在接口稳定的情况下可以省点事但在调试阶段纯属浪费时间。我的建议是先原样照抄跑通了再谈删减。跑通之后你甚至可以把每个字段单独去掉试一次记录哪些是必需的做成一张表放着以后接口变更时能快速判断哪些字段是新增的关键项。响应体的格式需要特别关注因为它决定了你的成败判断逻辑。常见有两种一种是返回 JSON里面有个明确的成功标志位比如{result: ok, msg: 认证成功}另一种是返回 HTML 页面成功和失败各自渲染不同的内容。前者好处理解析字段就行后者需要用关键字匹配比如判断有没有“成功”字样、有没有“密码错误”字样。我遇到过最难受的一种是无论成功失败都返回同样的状态码和同样的结构只能靠响应体里某个很隐晦的字段区分这种就要多试几次失败场景故意输错密码把失败时和成功时的响应分别存下来做 diff。2.4 哪些字段必须动态生成这一步是很多人卡住的关口。表单里那串看起来最像乱码的字段往往就是要动态生成的。判断方法很简单连续抓两次同样的登录请求把两次的请求体逐字段对比凡是值发生变化的就是动态字段值不变的可以固定下来。常见的动态字段有这么几类。第一类是时间戳和随机数这类通常直接生成即可不用逆向。第二类是账号密码的散列需要看前端 JS 里是怎么算的常见的是对密码做一次哈希再拼接一个盐值盐值可能是固定的也可能是从页面里取的。第三类是带签名的校验串把多个字段按特定顺序拼起来再哈希这种最麻烦必须把 JS 里的拼接顺序和哈希算法完整还原。还原 JS 的方法在开发者工具里搜提交接口的路径或者搜表单字段名定位到负责提交的那段脚本。如果代码没被混淆基本能直接读懂如果被混淆了就重点找哈希函数的调用点把入参和算法抠出来用 Python 复现。我做这个项目的时候密码字段的处理就是一次哈希算法在页面里明明白白写着直接用现成的库实现两行代码搞定。还有一个隐性的动态字段容易被忽略认证会话的有效期。有些网关在你打开认证页面时会种一个会话这个会话有生命周期比如几分钟内不提交就失效。如果你的脚本是先打开页面、隔了很久才提交就会失败。解决办法是把“取参数”和“提交”这两个动作放在紧邻的时间窗口内完成不要中间插入耗时的操作。3. 用 HTTP 客户端把认证流程跑通3.1 运行环境与依赖准备环境这块没什么特殊要求Python 3.8 以上就行主流发行版自带的版本都够用。依赖也很轻一个 HTTP 客户端库加一个哈希库就够后者标准库自带。安装命令大概是这样pip install requests如果你的环境里 pip 装包受限有些内网机器确实如此其实用标准库里的 HTTP 客户端也能实现只是要自己处理 Cookie 和编码麻烦一点。我倾向用第三方库因为会话管理、编码处理、超时控制这些都现成少写很多样板代码。代码组织上我建议至少分三个文件一个配置文件放账号密码和接口路径这个文件要排除在版本控制之外一个核心模块放认证和检测逻辑一个入口脚本负责调度。如果只是自己用写在一个文件里也行但请至少把凭据从代码里抽出来放到配置或者环境变量里这是最基本的习惯。我见过太多人把账号密码写死在脚本里然后传到公开仓库第二天发现账号被别人拿去用了。关于凭据存放我的具体做法是用环境变量配合一个简单的加载逻辑。这样做的好处是脚本本身可以随便复制、随便分享凭据不进代码坏处是调试时如果忘了设环境变量会报错。所以我还在代码里加了一个兜底环境变量读不到时从同目录下的配置文件读两个都没有就抛异常并给出明确提示。这种设计比“读到空字符串然后一路错到认证失败”要好排查得多。3.2 核心认证函数怎么写核心逻辑其实就三步取参数、拼表单、发请求。但每一步都有细节。先看整体结构import os import re import time import hashlib import logging import requests PORTAL_PROBE http://www.example.com # 用于触发重定向的探测地址 SUBMIT_PATH /portal/login # 提交接口路径需按实际填写 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Content-Type: application/x-www-form-urlencoded, } def grab_context(session, timeout5): 未认证状态下访问探测地址从重定向里捞上下文参数 resp session.get(PORTAL_PROBE, headersHEADERS, allow_redirectsFalse, timeouttimeout) location resp.headers.get(Location, ) if not location: # 网关没有返回 302可能是另一种拦截方式 return None ctx {} for key in (userip, wlanacname, nasip, wlanparameter): m re.search(r[?]{}([^]).format(key), location) ctx[key] m.group(1) if m else return ctxallow_redirectsFalse这一行是整个函数的关键前面提过不设置的话拿不到 Location 头。返回的字典里就是后续提交要用的位置类参数。如果location为空说明这次探测没有触发重定向可能是当前已经认证成功也可能是网关换了拦截方式两种情况要区分对待——先检查是不是已经在线再考虑格式问题。接着是提交函数def do_login(session, ctx, account, password): 拼装表单并提交返回是否成功 hashed hashlib.md5(password.encode(utf-8)).hexdigest() payload { account: account, password: hashed, # 按实际加密方式调整 userip: ctx.get(userip, ), wlanacname: ctx.get(wlanacname, ), nasip: ctx.get(nasip, ), wlanparameter: ctx.get(wlanparameter, ), jsVersion: 1.0, # 装饰类字段原样保留 ts: str(int(time.time() * 1000)), } url http:// ctx.get(nasip, ) SUBMIT_PATH try: resp session.post(url, datapayload, headersHEADERS, timeout8) except requests.RequestException as e: logging.warning(提交认证请求异常: %s, e) return False body resp.text if result:ok in body or 认证成功 in body: return True logging.info(认证返回: %s, body[:200]) return False这段代码里有几处需要你按实际情况调整的地方我在注释里标了。SUBMIT_PATH必须换成你抓到的真实路径密码的哈希方式如果不一样要改那两行成功判断的关键字也要按你的网关返回改。这几个地方是唯二硬编码的部分其余全部来自动态提取。提交地址我拼成了“接入设备 IP 路径”的形式这是常见情况但也见过提交地址和接入设备 IP 无关、固定指向认证服务器的情况。以你抓到的请求为准不要照抄。抓包时把那条 POST 请求的完整 URL 复制下来看看它和你提取到的哪个参数有关联再决定怎么拼。3.3 状态检测怎么判断自己掉线了检测逻辑的可靠性直接决定了整个方案的体验。做得糙的要么频繁误判导致反复重连网关那边可能还会因为短时间多次认证把你锁一会儿要么长时间掉线却毫无察觉。最简单的一招是访问一个已知的、返回内容固定的小页面判断返回内容是否符合预期。如果被重定向了说明掉线如果拿到正常内容说明在线。探测地址要选那种响应快、内容短、不依赖特定网络的比如某个公共的连通性检测接口。不要选大网站首页几百 KB 的页面拿来每十秒拉一次纯属浪费。def is_online(session, timeout4): try: resp session.get(PORTAL_PROBE, headersHEADERS, allow_redirectsFalse, timeouttimeout) except requests.RequestException: return None # 网络本身断了区别于被拦截 if resp.status_code in (301, 302, 303, 307, 308): loc resp.headers.get(Location, ) return not (portal in loc or login in loc or auth in loc) return resp.status_code 200注意这里返回三态而不是布尔值True表示在线False表示被拦截None表示请求本身失败了。这个区分很重要。如果返回None说明是链路问题此时去跑认证流程毫无意义——参数都取不到。正确的处理是先等一段时间看链路恢复没有恢复了再走认证。我做第一版的时候没区分这两种情况结果网线被拔的时候脚本拼命尝试认证日志刷了几百行全是失败硬盘都写热了。还有一个细节探测请求要带上和认证相同的会话。前面提过原因这里补充另一个理由——有些网关会根据会话里的 Cookie 识别客户端用新会话探测可能被当作未知设备判定结果不可靠。3.4 守护循环与重试节奏控制把上面三块串起来就是一个完整的守护循环。骨架很朴素但节奏控制有讲究def main_loop(): session requests.Session() session.trust_env False # 忽略系统代理设置 backoff 5 while True: state is_online(session) if state is True: backoff 5 time.sleep(15) continue if state is None: time.sleep(20) continue ctx grab_context(session) if not ctx or not ctx.get(userip): logging.info(未能获取认证上下文稍后重试) time.sleep(30) continue ok do_login(session, ctx, ACCOUNT, PASSWORD) logging.info(认证尝试结果: %s, ok) if not ok: time.sleep(backoff) backoff min(backoff * 2, 300) else: backoff 5 time.sleep(8) # 认证后稍等再验证这里有两个设计点值得展开。第一是退避。认证失败时不要固定间隔死磕网关一般都有失败次数限制短时间内连续失败可能触发临时锁定反而让情况更糟。用指数退避从 5 秒开始翻倍封顶 5 分钟既能快速恢复又不会把网关惹毛。第二是认证后的等待。提交成功后立刻去检测在线状态大概率还是判定为掉线因为网关那边的状态同步有延迟几百毫秒到两三秒都见过。所以认证成功后先等几秒再进入下一轮检测避免刚认证完就被自己误判成失败、再认证一次形成循环。session.trust_env False这一行也别忽略。很多开发机上配了环境级的代理变量requests 会老老实实遵守结果你的认证请求全走代理出去了网关根本看不到你的 IP自然认证失败。这个坑我踩过排查了大半天最后发现是代理环境变量在作祟。4. 让它长期稳定运行的几个关键动作4.1 开机自启与后台驻留脚本能跑起来只是开始能开机自动跑、断了能自己活过来才算真正省心。不同系统做法不一样我列一下我实际用过的几种。Windows 上最省事的是任务计划程序。新建任务触发器选“计算机启动时”和“用户登录时”两个操作里填 Python 解释器的完整路径作为程序脚本路径作为参数起始于填脚本所在目录这一项千万别漏否则相对路径的配置文件读不到。设置里勾上“如果任务失败按以下频率重新启动”间隔设 1 分钟重试 3 次。还有一个隐藏选项要打开在“常规”里选“不管用户是否登录都要运行”这样锁屏状态下也能工作。Linux 上就用 systemd 服务比 nohup 挂后台靠谱得多崩了会自动拉起[Unit] DescriptionPortal Auto Login Daemon Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple ExecStart/usr/bin/python3 /opt/portal/main.py WorkingDirectory/opt/portal Restartalways RestartSec30 EnvironmentPORTAL_ACCOUNTyour_account EnvironmentPORTAL_PASSWORDyour_password [Install] WantedBymulti-user.targetAfternetwork-online.target这一行很重要没有它服务可能在网络栈还没就绪时就启动第一次取参数必然失败。虽然靠重试也能恢复但日志里会多出一堆没用的报错看着心烦。Restartalways配合RestartSec30是兜底进程因为内存、异常之类的原因退出时能自动回来。如果跑在资源更紧张的设备上还可以考虑用定时任务代替常驻进程——每 5 分钟跑一次脚本检查一次、必要就认证一次跑完退出。这种做法内存占用几乎为零缺点是掉线后最长要等 5 分钟才恢复。取舍看你更在意资源还是恢复速度。4.2 凭据管理与日志脱敏这段单独拎出来讲因为它是安全问题里最容易出事的环节。三条底线凭据不进代码、凭据不进日志、凭据不进版本库。凭据不进代码前面说过用环境变量或者独立配置文件。配置文件的话Linux 上记得chmod 600Windows 上右键属性把继承权限去掉只留自己。凭据不进版本库靠的是版本控制工具的忽略规则把配置文件、日志文件都加进去。凭据不进日志是最容易被忽略的一条。调试阶段为了看请求体很多人会把整个 payload 打到日志里跑通之后忘了删。这等于把你的密码明文或者明文哈希一样危险存在了磁盘上而这个日志文件很可能被你随手打包发给别人求助。我的做法是在打日志的地方统一过一个脱敏函数SENSITIVE_KEYS (password, passwd, pwd, token, account) def mask(data): if isinstance(data, dict): return {k: (*** if k.lower() in SENSITIVE_KEYS else mask(v)) for k, v in data.items()} if isinstance(data, str) and len(data) 6: return data[:3] *** data[-2:] return data账号脱敏后保留首尾几位方便确认“是不是用错账号了”同时不至于把完整账号写进日志。这个函数实现很简单但能救命。另外日志轮转也要配一下不然跑几个月日志文件涨到几百 MB磁盘满了反而搞出一堆新问题。Python 标准库的日志模块自带按大小轮转的处理器配几行就行最大 10 MB保留 5 份够用了。提示如果你的脚本要分享给别人参考把配置文件里的真实凭据换成占位符检查一遍日志目录有没有一起打包。这两步花不了一分钟但泄露一次的成本很高。5. 出问题时的排查路径与避坑清单5.1 症状对照表从现象倒推原因这类脚本的失败现象高度集中我把自己遇到过的整理成一张表出问题时先按症状对号入座能省掉大半的盲目排查。现象大概率原因验证方法处理动作一直提示取不到上下文已处于认证状态或探测地址不通手动访问探测地址看是否直连换探测地址或先判断在线再取参请求成功但返回失败密码加密方式变了 / 字段缺失用浏览器抓一条成功的请求逐字段对比比对请求体差异补齐字段认证成功但很快又掉线同账号多设备互踢 / 会话已存在查看是否有其他终端在用同一账号单设备使用或错开使用时段偶尔成功偶尔失败参数带时效取参与提交间隔太久看失败日志的时间差把取参与提交合并到紧邻窗口本机手动能登录脚本不行环境变量里的代理被带上了打印实际使用的代理设置显式关闭代理继承日志里全是连接超时链路本身断了不是认证问题ping 内网网关等链路恢复加三态判断换了楼栋就失效接入设备标识硬编码对比新旧参数全部改为动态提取这张表里最想强调第一行和最后一行。第一行是新手的头号杀手你正处在认证状态访问任何地址都不会被重定向当然取不到上下文然后你开始怀疑网关、怀疑代码、怀疑人生。养成习惯动手前先确认自己现在是不是已经在线。最后一行则是“换环境就失效”的根源解决办法只有一个把所有位置类参数全部动态提取一个都别硬编码。这个原则我从第一版就坚持后面换过三次宿舍、两次实验室脚本一次都没改过。5.2 几个只有踩过才知道的细节局域网有多个认证入口时探测地址要选对。有些校园网分内外两个入口访问内网地址不会被拦截访问外网地址才会。如果你的探测地址选成了内网服务脚本会一直认为在线永远不触发认证。选一个明确在校园网外的公网地址做探测最保险。时间不同步会导致签名失效。如果表单里有时间戳参与签名而你的设备时间比标准时间差了几分钟签名就永远对不上。这个错误极其隐蔽因为请求格式完全正确就是返回“签名错误”。我那次是因为一台长期不联网的开发板时间漂移了十几分钟排查了一下午。之后我给所有设备都配了时间同步并且脚本启动时打印一次当前时间方便对照。认证成功后不要立刻高频检测。有些网关对短时间内的大量请求有防护你认证成功后每两秒探测一次可能被判为异常行为直接给你断掉。我现在的节奏是认证成功后等 8 秒做第一次确认之后正常间隔 15 秒稳定运行后可以放宽到 30 秒甚至 60 秒。掉线恢复的及时性对绝大多数使用场景来说30 秒完全够用。多网卡设备要指定出口。笔记本同时有线和无线、或者装了虚拟网卡时请求可能从错误的网卡出去导致网关看到的源 IP 和你提取的userip不一致认证直接失败。Windows 上可以临时禁用不用的网卡来验证Linux 上可以绑定源地址。这个问题在多虚拟机的开发机上特别常见我建议调试阶段就先把多余网卡关掉排除干扰。接口改版是必然会发生的做好心理准备。我维护这个脚本的几年里遇到过两次接口变更一次是字段名改了一次是加密方式从一次哈希变成了“哈希加盐”。两次都是通过“拿浏览器抓一条成功请求和脚本发出去的请求做 diff”定位的。所以我在代码里留了个调试开关打开后会把完整请求体和响应体脱敏后写到单独的文件里出问题时打开开关跑一次对比一下几分钟就能找到差异点。这个开关比什么文档都好使。最后说一句个人体会。这类脚本的价值不在于技术多复杂而在于它把一件每天要打断你好几次的小事彻底抹平了。真正花时间的从来不是写那几十行代码而是搞懂“为什么这个字段必须带”“为什么这里要等三秒”。把这几处理解透了以后碰到任何类似的网页表单自动化——无论是内网系统、老旧管理后台还是各种需要重复填表的场景——你都能用同一套方法快速拿下。
校园网认证这件事说小很小说烦是真烦。每天打开电脑浏览器弹出一个认证页面输入账号密码点登录一天掉线三五次每次都得重来一遍。如果手上还有一台常年开着的开发机、一台树莓派、几台虚拟机那这套动作一天要重复十几次。这篇内容就是把“手动点登录”这件事彻底自动化掉——核心手段就是用 POST 请求复现认证流程让脚本代替人去填表、提交、并在掉线后自动重连。关键词很明确校园网、POST 自动认证、断线重连、守护进程。它解决的不是什么高深问题而是“高频、低价值、必须人肉介入”的重复劳动。适合三类人看一是宿舍里被认证页面折磨到崩溃的普通用户照着步骤能跑起来就行二是想借这个场景练手的初学者Portal 认证是一个极好的 HTTP 抓包与协议还原练习比看教程敲一遍“爬虫入门”有用得多三是已经在做运维、嵌入式、自动化相关工作的朋友里面关于守护进程、日志脱敏、开机自启那几段可以直接搬走用。下面我按“搞懂它怎么运作 → 抓出关键参数 → 写出可跑的脚本 → 让它稳定活下来 → 出问题怎么查”这条线把整个过程摊开讲。1. 先把认证流程拆明白再动手1.1 一次手动登录背后到底发生了什么很多人一上来就去抓包抓完发现一堆参数看不懂卡在这里就放弃了。我的建议是先别急着开工具先在脑子里建立一个模型你点“登录”的那一瞬间浏览器至少完成了三件事——获取认证入口地址、拼装表单参数、向网关提交并接收结果。这三件事对应三段不同的网络行为抓包时要把它们分清楚否则会把“跳转”当成“提交”把“页面渲染”当成“接口返回”。具体来说连上校园 Wi-Fi 或网线后你的设备拿到一个内网地址。此时访问任何外部站点网关并不会直接放行而是把你的请求拦下来返回一个重定向把你引导到认证服务器上的一个页面。这个页面的地址里通常带着一串查询参数比如你的终端 IP、接入设备的标识、原始访问的目标地址等等。这些参数就是后续提交时要用到的“上下文”丢一个都可能导致认证失败。这就是为什么很多人直接抄别人的脚本跑不通——别人的 IP 和你不一样接入设备标识也不一样。认证页面加载完之后里面嵌着一个表单表单的提交地址往往和页面地址不是同一个域名或路径。你填账号密码点提交浏览器把表单数据以 POST 形式发到这个地址网关校验通过后返回一段结果可能是 JSON也可能是跳转到一个成功提示页同时在你这个 IP 上打一个“已认证”的标记之后你的流量才被放行。理解了这个“先重定向、再提交、后放行”的三段式结构抓包时你就知道该盯哪几个请求了。这里有个很容易被忽略的点认证状态是绑定在 IP有时还叠加 MAC上的不是绑定在你的设备身份上。这意味着两件事。第一你换一个 IP比如从 Wi-Fi 切到有线、或者 DHCP 重新分配就需要重新认证一次。第二如果同一网段里有人手动填了和你一样的 IP 配置会导致双方都认证不上或者互相踢下线这是宿舍里常见的“玄学掉线”原因之一。知道这一点后面写断线检测逻辑时你就明白光判断“网络通不通”是不够的得判断“我这个 IP 的认证标记还在不在”。1.2 三条技术路线为什么最后选了模拟 POST自动化认证这件事业内有三种常见做法各有各的适用场景我在不同阶段都用过这里做个横向对比方便你按自己的情况选。路线实现方式资源占用稳定性维护成本适用情况模拟 POST 请求用 HTTP 客户端直接提交表单极低几 MB 内存高但惧怕接口变更中接口变了要重抓绝大多数场景首选浏览器自动化无头浏览器加载页面并点击高几百 MB中页面改版即失效高页面有复杂 JS 加密或验证码图形界面模拟模拟鼠标键盘点击中低窗口焦点一变就崩高实在没办法时的兜底第一种是首选因为它最轻、最快、最容易做成后台常驻。缺点也很直白一旦认证页面改版、参数增减、加密方式变化脚本立刻失效需要重新抓包调整。第二种的好处是“所见即所得”页面上人怎么点脚本就怎么点对 JS 加密、动态渲染的兼容性好得多代价是资源占用高跑在宿舍那台常年开机的旧笔记本上还行跑在树莓派上就有点吃力而且无头浏览器在很多环境里会因为缺少图形依赖而启动失败。第三种我是真不推荐除非前两条路都走死了。它的脆弱程度超出想象系统弹个通知、分辨率变一下、输入法切一下坐标就全偏了。而且它必须依赖一个可见的桌面会话远程或者无人值守时完全没法用。我最终落在第一条路上还有一个很实际的原因校园网认证接口通常极其简陋。它不需要考虑多终端适配、不需要考虑无障碍、不会有复杂的风控所以前端那点加密手段往往就是一层简单的哈希看一眼 JS 就能还原。投入产出比高得离谱。反过来说如果你抓包后发现密码字段是一长串看不懂的密文且 JS 被严重混淆那再考虑退到第二条路。注意这套自动化的前提是使用你自己的账号、你自己名下的终端设备。把自己的账号密码交给脚本去跑本质上和你在浏览器里手动输入没有区别但请不要把脚本分享给他人共用账号也不要把凭据硬编码后推到公开仓库这是最容易被忽略的安全问题。1.3 方案的整体骨架长什么样在正式动手前先把最终形态想清楚避免写到一半推翻重来。我的脚本整体是四层结构参数采集层负责在未认证状态下捕获重定向拿到 IP、接入设备标识等上下文认证执行层负责拼装表单并提交解析返回结果状态检测层负责周期性判断当前是否在线守护调度层负责串联前三层处理异常、记录日志、控制重试节奏。分层的好处是每一层都能独立调试。新手最容易犯的错是把所有逻辑塞进一个大函数里一旦失败根本不知道是参数取错了、提交格式错了、还是判断在线状态的逻辑本身有 bug。分成四层之后你可以单独测“参数采集”打印出来和人家的成功请求对比也可以单独测“状态检测”手动断网看它能不能正确识别。这种可拆解性在排查问题时价值极大。另外提前说清楚一个设计取舍认证和检测要共用同一个会话对象。有些网关会在认证成功后下发 Cookie后续的状态检测如果用一个全新的会话来发请求可能被当成未认证的新客户端从而误判掉线触发无意义的重连。共用会话还能复用底层的 TCP 连接减少握手开销在检测频率较高时比如每 10 秒一次这个差别是能感知到的。2. 抓包还原把认证参数一个一个抠出来2.1 抓包前的环境准备工欲善其事。抓包这一步我建议在电脑上做不要在手机或开发板上做因为你需要看完整的请求头、请求体、响应头和响应体。浏览器自带的开发者工具就够了不需要额外装软件。打开方式是按 F12 或者右键检查切到“网络”面板勾上“保留日志”和“停用缓存”两个选项——这两个勾非常关键不勾的话页面一跳转之前的请求记录就全被清空了你会对着空白面板怀疑人生。准备工作还有一个容易被忽略的细节先把当前认证状态清掉。如果你现在是已认证状态访问任何网站都直接通根本不会触发重定向自然抓不到认证流程。正确做法是找到认证页面主动点一次“注销/下线”或者干脆等它自然超时。有些网关的注销入口藏得很深可以先访问认证服务器的根路径试试。然后清空网络面板的记录点一次注销再随便访问一个外部站点看着页面被重定向到认证页这时候网络面板里就会出现完整的一串请求。整个过程保持面板打开不要刷新页面。我第一次做的时候就是因为中途刷新了一下日志清空白忙活二十分钟。工具方面浏览器开发者工具适合看单次请求的细节如果你需要看多次重连之间的差异、或者想批量比对参数变化那就需要一个能保存请求记录的工具比如把请求导出成 HAR 文件或者用命令行工具把请求完整打印出来。我在调参阶段习惯把每次请求的完整 URL 和请求体写进一个日志文件方便事后 grep 对比这个习惯帮我定位过好几次“某个字段悄悄变了”的问题。2.2 从重定向里提取上下文参数第一段要抓的是重定向。你在未认证状态下访问一个外部地址比如某个常见的公共 DNS 探测页网关会返回一个 302响应头里的 Location 字段就是认证页面的完整地址。这个地址长这样参数名做了抽象处理http://认证服务器地址/portal页面?userip10.x.x.xwlanacnameAC-XXXnasip10.x.x.xwlanparameterxxxxurlhttp://你原本要访问的地址这里面的每一个参数都不是摆设。userip是你的终端在校园网内网里的地址网关靠它定位“给谁放行”wlanacname和nasip标识你连的是哪个接入设备多校区、多楼栋的校园网里这个值千差万别硬编码必挂wlanparameter通常是加密过的会话标识有时效性隔一段时间就失效不能缓存复用。我的做法是不硬编码任何一个参数而是每次认证前先主动发一次请求故意让它被重定向然后从 302 响应里用正则把这几个参数抽出来。这样即使换了楼栋、换了设备、IP 变了脚本也能自适应。这一步是整个方案健壮性的基石比后面写多漂亮的代码都重要。具体实现上有个坑Python 的 requests 默认会自动跟随重定向你拿到的就是最终页面看不到中间的 302。所以要么在请求时把allow_redirects设为False手动读headers[Location]要么关闭自动重定向后自己决定下一步。我一开始就是被这个默认行为坑了打印出来全是 HTML找不到 Location 头还以为是网关不返回重定向。提示如果你发现访问外部地址时根本没有 302而是直接返回了一个认证页面的 HTML说明这个网关用的是另一种拦截方式返回 200 但内容是认证页。这时候就从 HTML 里用正则提取参数思路是一样的只是提取源从响应头变成了响应体。2.3 表单提交接口与字段含义第二段要抓的是真正的提交请求。在认证页面上填好账号密码点登录网络面板里会多出一条 POST 请求。这条请求有几个必须记录下来的信息请求 URL提交的目标地址通常和页面地址不同、Content-Type多半是表单编码少数是 JSON、请求体的完整字段列表、以及响应体的格式。请求体里的字段可以分成三类理解分类能帮你在接口变更时快速定位问题。第一类是身份类账号、密码或者密码的哈希。第二类是位置类终端 IP、接入设备标识、接入设备 IP这些基本都来自上一步提取的上下文是动态的。第三类是装饰类加密方式标记、客户端类型、版本号、时间戳、随机数、回调函数名等等这些字段看着没意义但缺一个就可能被拒绝必须原样带上。我见过有人为了“精简”请求把看起来没用的字段一个个删掉试最后发现某个叫jsVersion的字段是必须的。这种逆向式的精简在接口稳定的情况下可以省点事但在调试阶段纯属浪费时间。我的建议是先原样照抄跑通了再谈删减。跑通之后你甚至可以把每个字段单独去掉试一次记录哪些是必需的做成一张表放着以后接口变更时能快速判断哪些字段是新增的关键项。响应体的格式需要特别关注因为它决定了你的成败判断逻辑。常见有两种一种是返回 JSON里面有个明确的成功标志位比如{result: ok, msg: 认证成功}另一种是返回 HTML 页面成功和失败各自渲染不同的内容。前者好处理解析字段就行后者需要用关键字匹配比如判断有没有“成功”字样、有没有“密码错误”字样。我遇到过最难受的一种是无论成功失败都返回同样的状态码和同样的结构只能靠响应体里某个很隐晦的字段区分这种就要多试几次失败场景故意输错密码把失败时和成功时的响应分别存下来做 diff。2.4 哪些字段必须动态生成这一步是很多人卡住的关口。表单里那串看起来最像乱码的字段往往就是要动态生成的。判断方法很简单连续抓两次同样的登录请求把两次的请求体逐字段对比凡是值发生变化的就是动态字段值不变的可以固定下来。常见的动态字段有这么几类。第一类是时间戳和随机数这类通常直接生成即可不用逆向。第二类是账号密码的散列需要看前端 JS 里是怎么算的常见的是对密码做一次哈希再拼接一个盐值盐值可能是固定的也可能是从页面里取的。第三类是带签名的校验串把多个字段按特定顺序拼起来再哈希这种最麻烦必须把 JS 里的拼接顺序和哈希算法完整还原。还原 JS 的方法在开发者工具里搜提交接口的路径或者搜表单字段名定位到负责提交的那段脚本。如果代码没被混淆基本能直接读懂如果被混淆了就重点找哈希函数的调用点把入参和算法抠出来用 Python 复现。我做这个项目的时候密码字段的处理就是一次哈希算法在页面里明明白白写着直接用现成的库实现两行代码搞定。还有一个隐性的动态字段容易被忽略认证会话的有效期。有些网关在你打开认证页面时会种一个会话这个会话有生命周期比如几分钟内不提交就失效。如果你的脚本是先打开页面、隔了很久才提交就会失败。解决办法是把“取参数”和“提交”这两个动作放在紧邻的时间窗口内完成不要中间插入耗时的操作。3. 用 HTTP 客户端把认证流程跑通3.1 运行环境与依赖准备环境这块没什么特殊要求Python 3.8 以上就行主流发行版自带的版本都够用。依赖也很轻一个 HTTP 客户端库加一个哈希库就够后者标准库自带。安装命令大概是这样pip install requests如果你的环境里 pip 装包受限有些内网机器确实如此其实用标准库里的 HTTP 客户端也能实现只是要自己处理 Cookie 和编码麻烦一点。我倾向用第三方库因为会话管理、编码处理、超时控制这些都现成少写很多样板代码。代码组织上我建议至少分三个文件一个配置文件放账号密码和接口路径这个文件要排除在版本控制之外一个核心模块放认证和检测逻辑一个入口脚本负责调度。如果只是自己用写在一个文件里也行但请至少把凭据从代码里抽出来放到配置或者环境变量里这是最基本的习惯。我见过太多人把账号密码写死在脚本里然后传到公开仓库第二天发现账号被别人拿去用了。关于凭据存放我的具体做法是用环境变量配合一个简单的加载逻辑。这样做的好处是脚本本身可以随便复制、随便分享凭据不进代码坏处是调试时如果忘了设环境变量会报错。所以我还在代码里加了一个兜底环境变量读不到时从同目录下的配置文件读两个都没有就抛异常并给出明确提示。这种设计比“读到空字符串然后一路错到认证失败”要好排查得多。3.2 核心认证函数怎么写核心逻辑其实就三步取参数、拼表单、发请求。但每一步都有细节。先看整体结构import os import re import time import hashlib import logging import requests PORTAL_PROBE http://www.example.com # 用于触发重定向的探测地址 SUBMIT_PATH /portal/login # 提交接口路径需按实际填写 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Content-Type: application/x-www-form-urlencoded, } def grab_context(session, timeout5): 未认证状态下访问探测地址从重定向里捞上下文参数 resp session.get(PORTAL_PROBE, headersHEADERS, allow_redirectsFalse, timeouttimeout) location resp.headers.get(Location, ) if not location: # 网关没有返回 302可能是另一种拦截方式 return None ctx {} for key in (userip, wlanacname, nasip, wlanparameter): m re.search(r[?]{}([^]).format(key), location) ctx[key] m.group(1) if m else return ctxallow_redirectsFalse这一行是整个函数的关键前面提过不设置的话拿不到 Location 头。返回的字典里就是后续提交要用的位置类参数。如果location为空说明这次探测没有触发重定向可能是当前已经认证成功也可能是网关换了拦截方式两种情况要区分对待——先检查是不是已经在线再考虑格式问题。接着是提交函数def do_login(session, ctx, account, password): 拼装表单并提交返回是否成功 hashed hashlib.md5(password.encode(utf-8)).hexdigest() payload { account: account, password: hashed, # 按实际加密方式调整 userip: ctx.get(userip, ), wlanacname: ctx.get(wlanacname, ), nasip: ctx.get(nasip, ), wlanparameter: ctx.get(wlanparameter, ), jsVersion: 1.0, # 装饰类字段原样保留 ts: str(int(time.time() * 1000)), } url http:// ctx.get(nasip, ) SUBMIT_PATH try: resp session.post(url, datapayload, headersHEADERS, timeout8) except requests.RequestException as e: logging.warning(提交认证请求异常: %s, e) return False body resp.text if result:ok in body or 认证成功 in body: return True logging.info(认证返回: %s, body[:200]) return False这段代码里有几处需要你按实际情况调整的地方我在注释里标了。SUBMIT_PATH必须换成你抓到的真实路径密码的哈希方式如果不一样要改那两行成功判断的关键字也要按你的网关返回改。这几个地方是唯二硬编码的部分其余全部来自动态提取。提交地址我拼成了“接入设备 IP 路径”的形式这是常见情况但也见过提交地址和接入设备 IP 无关、固定指向认证服务器的情况。以你抓到的请求为准不要照抄。抓包时把那条 POST 请求的完整 URL 复制下来看看它和你提取到的哪个参数有关联再决定怎么拼。3.3 状态检测怎么判断自己掉线了检测逻辑的可靠性直接决定了整个方案的体验。做得糙的要么频繁误判导致反复重连网关那边可能还会因为短时间多次认证把你锁一会儿要么长时间掉线却毫无察觉。最简单的一招是访问一个已知的、返回内容固定的小页面判断返回内容是否符合预期。如果被重定向了说明掉线如果拿到正常内容说明在线。探测地址要选那种响应快、内容短、不依赖特定网络的比如某个公共的连通性检测接口。不要选大网站首页几百 KB 的页面拿来每十秒拉一次纯属浪费。def is_online(session, timeout4): try: resp session.get(PORTAL_PROBE, headersHEADERS, allow_redirectsFalse, timeouttimeout) except requests.RequestException: return None # 网络本身断了区别于被拦截 if resp.status_code in (301, 302, 303, 307, 308): loc resp.headers.get(Location, ) return not (portal in loc or login in loc or auth in loc) return resp.status_code 200注意这里返回三态而不是布尔值True表示在线False表示被拦截None表示请求本身失败了。这个区分很重要。如果返回None说明是链路问题此时去跑认证流程毫无意义——参数都取不到。正确的处理是先等一段时间看链路恢复没有恢复了再走认证。我做第一版的时候没区分这两种情况结果网线被拔的时候脚本拼命尝试认证日志刷了几百行全是失败硬盘都写热了。还有一个细节探测请求要带上和认证相同的会话。前面提过原因这里补充另一个理由——有些网关会根据会话里的 Cookie 识别客户端用新会话探测可能被当作未知设备判定结果不可靠。3.4 守护循环与重试节奏控制把上面三块串起来就是一个完整的守护循环。骨架很朴素但节奏控制有讲究def main_loop(): session requests.Session() session.trust_env False # 忽略系统代理设置 backoff 5 while True: state is_online(session) if state is True: backoff 5 time.sleep(15) continue if state is None: time.sleep(20) continue ctx grab_context(session) if not ctx or not ctx.get(userip): logging.info(未能获取认证上下文稍后重试) time.sleep(30) continue ok do_login(session, ctx, ACCOUNT, PASSWORD) logging.info(认证尝试结果: %s, ok) if not ok: time.sleep(backoff) backoff min(backoff * 2, 300) else: backoff 5 time.sleep(8) # 认证后稍等再验证这里有两个设计点值得展开。第一是退避。认证失败时不要固定间隔死磕网关一般都有失败次数限制短时间内连续失败可能触发临时锁定反而让情况更糟。用指数退避从 5 秒开始翻倍封顶 5 分钟既能快速恢复又不会把网关惹毛。第二是认证后的等待。提交成功后立刻去检测在线状态大概率还是判定为掉线因为网关那边的状态同步有延迟几百毫秒到两三秒都见过。所以认证成功后先等几秒再进入下一轮检测避免刚认证完就被自己误判成失败、再认证一次形成循环。session.trust_env False这一行也别忽略。很多开发机上配了环境级的代理变量requests 会老老实实遵守结果你的认证请求全走代理出去了网关根本看不到你的 IP自然认证失败。这个坑我踩过排查了大半天最后发现是代理环境变量在作祟。4. 让它长期稳定运行的几个关键动作4.1 开机自启与后台驻留脚本能跑起来只是开始能开机自动跑、断了能自己活过来才算真正省心。不同系统做法不一样我列一下我实际用过的几种。Windows 上最省事的是任务计划程序。新建任务触发器选“计算机启动时”和“用户登录时”两个操作里填 Python 解释器的完整路径作为程序脚本路径作为参数起始于填脚本所在目录这一项千万别漏否则相对路径的配置文件读不到。设置里勾上“如果任务失败按以下频率重新启动”间隔设 1 分钟重试 3 次。还有一个隐藏选项要打开在“常规”里选“不管用户是否登录都要运行”这样锁屏状态下也能工作。Linux 上就用 systemd 服务比 nohup 挂后台靠谱得多崩了会自动拉起[Unit] DescriptionPortal Auto Login Daemon Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple ExecStart/usr/bin/python3 /opt/portal/main.py WorkingDirectory/opt/portal Restartalways RestartSec30 EnvironmentPORTAL_ACCOUNTyour_account EnvironmentPORTAL_PASSWORDyour_password [Install] WantedBymulti-user.targetAfternetwork-online.target这一行很重要没有它服务可能在网络栈还没就绪时就启动第一次取参数必然失败。虽然靠重试也能恢复但日志里会多出一堆没用的报错看着心烦。Restartalways配合RestartSec30是兜底进程因为内存、异常之类的原因退出时能自动回来。如果跑在资源更紧张的设备上还可以考虑用定时任务代替常驻进程——每 5 分钟跑一次脚本检查一次、必要就认证一次跑完退出。这种做法内存占用几乎为零缺点是掉线后最长要等 5 分钟才恢复。取舍看你更在意资源还是恢复速度。4.2 凭据管理与日志脱敏这段单独拎出来讲因为它是安全问题里最容易出事的环节。三条底线凭据不进代码、凭据不进日志、凭据不进版本库。凭据不进代码前面说过用环境变量或者独立配置文件。配置文件的话Linux 上记得chmod 600Windows 上右键属性把继承权限去掉只留自己。凭据不进版本库靠的是版本控制工具的忽略规则把配置文件、日志文件都加进去。凭据不进日志是最容易被忽略的一条。调试阶段为了看请求体很多人会把整个 payload 打到日志里跑通之后忘了删。这等于把你的密码明文或者明文哈希一样危险存在了磁盘上而这个日志文件很可能被你随手打包发给别人求助。我的做法是在打日志的地方统一过一个脱敏函数SENSITIVE_KEYS (password, passwd, pwd, token, account) def mask(data): if isinstance(data, dict): return {k: (*** if k.lower() in SENSITIVE_KEYS else mask(v)) for k, v in data.items()} if isinstance(data, str) and len(data) 6: return data[:3] *** data[-2:] return data账号脱敏后保留首尾几位方便确认“是不是用错账号了”同时不至于把完整账号写进日志。这个函数实现很简单但能救命。另外日志轮转也要配一下不然跑几个月日志文件涨到几百 MB磁盘满了反而搞出一堆新问题。Python 标准库的日志模块自带按大小轮转的处理器配几行就行最大 10 MB保留 5 份够用了。提示如果你的脚本要分享给别人参考把配置文件里的真实凭据换成占位符检查一遍日志目录有没有一起打包。这两步花不了一分钟但泄露一次的成本很高。5. 出问题时的排查路径与避坑清单5.1 症状对照表从现象倒推原因这类脚本的失败现象高度集中我把自己遇到过的整理成一张表出问题时先按症状对号入座能省掉大半的盲目排查。现象大概率原因验证方法处理动作一直提示取不到上下文已处于认证状态或探测地址不通手动访问探测地址看是否直连换探测地址或先判断在线再取参请求成功但返回失败密码加密方式变了 / 字段缺失用浏览器抓一条成功的请求逐字段对比比对请求体差异补齐字段认证成功但很快又掉线同账号多设备互踢 / 会话已存在查看是否有其他终端在用同一账号单设备使用或错开使用时段偶尔成功偶尔失败参数带时效取参与提交间隔太久看失败日志的时间差把取参与提交合并到紧邻窗口本机手动能登录脚本不行环境变量里的代理被带上了打印实际使用的代理设置显式关闭代理继承日志里全是连接超时链路本身断了不是认证问题ping 内网网关等链路恢复加三态判断换了楼栋就失效接入设备标识硬编码对比新旧参数全部改为动态提取这张表里最想强调第一行和最后一行。第一行是新手的头号杀手你正处在认证状态访问任何地址都不会被重定向当然取不到上下文然后你开始怀疑网关、怀疑代码、怀疑人生。养成习惯动手前先确认自己现在是不是已经在线。最后一行则是“换环境就失效”的根源解决办法只有一个把所有位置类参数全部动态提取一个都别硬编码。这个原则我从第一版就坚持后面换过三次宿舍、两次实验室脚本一次都没改过。5.2 几个只有踩过才知道的细节局域网有多个认证入口时探测地址要选对。有些校园网分内外两个入口访问内网地址不会被拦截访问外网地址才会。如果你的探测地址选成了内网服务脚本会一直认为在线永远不触发认证。选一个明确在校园网外的公网地址做探测最保险。时间不同步会导致签名失效。如果表单里有时间戳参与签名而你的设备时间比标准时间差了几分钟签名就永远对不上。这个错误极其隐蔽因为请求格式完全正确就是返回“签名错误”。我那次是因为一台长期不联网的开发板时间漂移了十几分钟排查了一下午。之后我给所有设备都配了时间同步并且脚本启动时打印一次当前时间方便对照。认证成功后不要立刻高频检测。有些网关对短时间内的大量请求有防护你认证成功后每两秒探测一次可能被判为异常行为直接给你断掉。我现在的节奏是认证成功后等 8 秒做第一次确认之后正常间隔 15 秒稳定运行后可以放宽到 30 秒甚至 60 秒。掉线恢复的及时性对绝大多数使用场景来说30 秒完全够用。多网卡设备要指定出口。笔记本同时有线和无线、或者装了虚拟网卡时请求可能从错误的网卡出去导致网关看到的源 IP 和你提取的userip不一致认证直接失败。Windows 上可以临时禁用不用的网卡来验证Linux 上可以绑定源地址。这个问题在多虚拟机的开发机上特别常见我建议调试阶段就先把多余网卡关掉排除干扰。接口改版是必然会发生的做好心理准备。我维护这个脚本的几年里遇到过两次接口变更一次是字段名改了一次是加密方式从一次哈希变成了“哈希加盐”。两次都是通过“拿浏览器抓一条成功请求和脚本发出去的请求做 diff”定位的。所以我在代码里留了个调试开关打开后会把完整请求体和响应体脱敏后写到单独的文件里出问题时打开开关跑一次对比一下几分钟就能找到差异点。这个开关比什么文档都好使。最后说一句个人体会。这类脚本的价值不在于技术多复杂而在于它把一件每天要打断你好几次的小事彻底抹平了。真正花时间的从来不是写那几十行代码而是搞懂“为什么这个字段必须带”“为什么这里要等三秒”。把这几处理解透了以后碰到任何类似的网页表单自动化——无论是内网系统、老旧管理后台还是各种需要重复填表的场景——你都能用同一套方法快速拿下。
