Python+计划任务实现校园网自动认证与断网重连教程

1. 写在前面：被校园网认证逼疯的人，不止你一个

每次开机第一件事不是打开微信，而是掏出手机找校园网认证页面，等它加载完再输入账号密码点登录。要是哪天网络波动一下，正打游戏打到一半突然掉线，回桌面重新点开浏览器，重新认证，重新连接，那个烦躁劲儿，用过校园网的都懂。江西理工大学的校园网就是典型的Web认证方式，电脑接入后不会直接通网，必须通过浏览器跳转到认证页面，输入学号和密码才能正常上网。这个流程本身不复杂，但架不住每天都要重复，而且高峰时段认证页面偶尔还会卡顿。

我写这套东西的起因很简单：2023年5月20日那天，我在宿舍抢课，结果认证页面死活刷新不出来，等我好不容易登进去，课已经没了。那天晚上我就下决心，必须搞一套能自动连接、自动重连的方案出来。折腾了几天，终于把整套流程跑通了，从开机到校园网正常在线，全程不需要任何手动操作。如果你也受够了每天手动认证，或者经常因为掉线而崩溃，这篇教程就是给你准备的。

这篇教程全程围绕Windows系统展开，适合江西理工大学（以及认证方式类似的兄弟院校）的同学直接照抄。整个方案不需要额外买硬件，不涉及任何违反校园网使用规则的操作，只是在你的电脑上配置一套自动化脚本，让电脑自己完成认证、检测、重连这套循环。所需工具全部免费，动手能力零基础也能跟下来。

2. 先搞清楚校园网是怎么认证的，再谈自动化

2.1 为什么校园网这么容易掉线

江西理工的校园网和我见过的很多高校一样，走的是标准的Web认证模式。你的电脑连上校园网Wi-Fi或者插上网线之后，网络层其实已经通了，但所有HTTP请求都会被防火墙拦截并重定向到认证页面。只有你在认证页面提交了正确的学号和密码，后台系统才会把你这台设备的MAC地址加进白名单，这时候网络才真正可用。

这种认证方式有一个非常坑的特点：它不是一次认证永久生效的。学校服务器会定期清理在线会话，比如DHCP租约到期、交换机端口检测到空闲超时、关联的IP地址发生变化，都会导致网络断开。另外宿舍楼里晚上断网断电，早晨来电时网卡刚启动，网络状态也是断开的。所以“刚开机需要认证”只是问题的一半，“用着用着突然掉线需要重新认证”才是更频繁、更烦人的另一半。

2.2 自动化方案的三种路线，我为什么选脚本

想解决自动连接和自动重连，一般有下面三条路线：

第一条，用现成的第三方拨号/认证工具。这类工具网上不少，有不少是针对校园网开发的，原理是在后台模拟浏览器向认证服务器提交请求。优点是真的省事，下载安装就行；缺点也很明显，来源不明的工具你敢装吗？很多工具需要注册登录、内置广告、甚至有收集账号密码的风险，我建议直接排除。

第二条，用Windows计划任务写批处理脚本调起浏览器自动登录。这个方案也有不少人用，思路是开机后打开默认浏览器访问认证页面，再通过JavaScript或浏览器自动填表功能提交账号密码。好处是不用手工点击了，但实际用起来问题不少：浏览器启动慢、自动填表偶尔失效、断网重连时还得再拉起一次浏览器，体验很粗糙。

第三条，就是我自己用的方案：Python脚本模拟认证请求。通过抓包拿到认证页面的提交接口，然后用脚本直接向服务器发一条POST请求，把账号密码传过去。配合网络连通性检测，一旦发现断网就自动重新提交认证请求。整个流程不依赖浏览器，后台静默运行，占用资源极低。这个方案的难点在于需要会一点Python，需要会抓包，但这些我会一步步教你，并不难。

我最终选择了第三条路线，核心原因是它最稳定，也最可控。脚本是开源的，逻辑完全透明，账号密码只保存在本地，不存在第三方工具的安全隐患。而且脚本天然适合做成开机自启服务，配合检测逻辑就能同时实现“开机自动连接”和“断网自动重连”两个需求。

2.3 自动化脚本的整体工作流程

整套自动化系统的核心逻辑其实就三句话：检测网络通不通，不通就去认证，通了就继续盯着。拆开来看是这样的：

开机之后，计划任务启动Python后台脚本。脚本首先检查当前网络是否通畅，如果通畅就进入静默监测状态，每隔一段时间（我设的是5秒）检测一次网络连通性。一旦发现断网，脚本不会盲目去认证，而是先判断当前是否还连着校园网Wi-Fi（如果连的是手机热点，就不该触发认证逻辑），确认无误后再向认证服务器提交账号密码，然后再次检测网络是否恢复。恢复后回到静默监测状态，如此循环。

这套逻辑听起来简单，但做起来有不少细节需要考虑。比如认证提交后服务器返回成功，但网络仍然不通，这种情况很可能就是IP地址没拿到，需要重启网卡；再比如断网检测频率太高会白白耗费资源，太低又会延迟恢复。这些问题我在下面的内容里都会逐一讲到，配置完你就明白了。

3. 准备工作：抓包获取认证请求

3.1 确认你的校园网认证是网页版还是客户端版

江西理工大学校园网用的是网页认证，也就是上面说的Web认证模式。但为了防止有同学遇到的情况不同，这里还是给一个快速判断方法：先把电脑网线插好或者连上校园网Wi-Fi，然后打开浏览器随便访问一个网站，如果页面自动跳转到一个有登录框的页面，要求输入学号和密码，那就是Web认证。

如果打开浏览器之后弹出一个独立的认证客户端，要求你下载某个软件才能上网，那就是客户端认证。江西理工目前没有使用客户端认证，但如果哪天学校更换了认证系统，脚本方案就需要相应调整。所以第一步请大家务必先确认自己的认证页面长什么样，下面是重点。

3.2 用浏览器开发者工具抓取认证接口

要让Python脚本模拟认证，必须知道认证页面提交的请求地址、参数格式和返回结果。这一步就叫“抓包”，我用的是最简单的方法：按F12打开浏览器开发者工具。

先别急着登录，保持开发者工具打开，在Network（网络）面板里勾选Preserve log（保留日志），然后正常输入账号密码登录。登录成功后，开发者工具里会记录下网络请求列表。我们需要重点找一条POST请求，它的名称通常是login、doLogin、auth之类的，对应的是“提交登录表单”这个动作。

找到这条请求后，点击它查看详情，里面会有关键信息：Request URL（请求地址）、Request Method（请求方法）、Form Data（表单参数）。把这些内容记下来。我当时抓到的请求地址大概是这样的结构：http://xxx.xxx.xxx.xxx:801/eportal/portal/login，表单参数有userId、password、service等字段，不同学校参数名不同。

这里有个重要提醒：密码字段一般不是明文，而是经过加密的。我抓包时发现密码是经过MD5加密后的字符串，所以脚本里不能直接传原始密码，需要先用hashlib库做同样的加密再提交。如果你抓包看到的是明文，那更省事；如果是加密的，观察一下是不是MD5或者Base64，Python里都用标准库就能处理。

3.3 用Python构造并测试认证请求

拿到接口和参数格式之后，先用Python写一个最基础的单次认证脚本，手动跑一次确认能成功。我建议用requests库，这是Python里最常用的HTTP请求库。

import requests import hashlib # 这里替换成你实际抓到的接口地址 login_url = "http://xxx.xxx.xxx.xxx:801/eportal/portal/login" # 构造参数 data = { "userId": "你的学号", "password": hashlib.md5("你的密码".encode()).hexdigest(), "service": "校园网服务标识", # 按实际抓包为准 } # 发送认证请求 resp = requests.post(login_url, data=data, timeout=5) # 打印返回结果，观察是否认证成功 print(resp.text)

第一次运行的时候，大概率不会一次成功。别着急，逐个对照抓包数据检查：地址是否完全一致？参数名是否拼错？密码加密方式是否正确？请求头里有没有额外的Content-Type要求？我当时卡在了密码加密上，后来仔细看抓包里的JS代码才发现登录页面在提交前先执行了MD5加密，改过来之后一次就通了。

验证成功之后，把这个单次认证功能封装成一个函数，后面所有的自动化逻辑都围绕这个函数展开。

4. 编写断网检测与自动重连核心脚本

4.1 网络连通性检测的两种方式

脚本的核心功能是“检测断网”，这里检测方式的选择很关键。最基础的是ping网关或DNS，但实际用下来我发现一个坑：在某些情况下，校园网虽然已经断开认证，但ping内网地址仍然是通的，因为内网网段和认证系统在同一层网络里。如果只ping内网，会出现“该设备已在网络中存在但没有外网访问权限”的误判。

更可靠的检测方式是“HTTP请求检测”：请求一个外网地址，比如百度的首页或者某个响应稳定的公共DNS的HTTP服务，只要返回状态码是200，就说明外网是通的。这个方式能准确反映“是否拥有真正的互联网访问能力”，同时配合ping网关判断“网卡链路是否正常”，两者结合就能区分以下几种情况：

• 外网通、内网通：一切正常，不需要处理。
• 外网不通、内网通：大概率是认证失效，触发重新认证。
• 外网不通、内网也不通：可能是网卡没连上Wi-Fi或者网线松了，先尝试重新连接网络，而不是急着认证。

我实测下来，用requests请求一个固定网址，超时设为3秒，非常稳定。但有个小细节要注意：不要每次检测都请求同一个大型网站，免得给对方服务器增加无谓负担，也避免学校网络拥堵时误判。我一般用https://www.baidu.com，响应速度快，稳定性高。

4.2 编写断网自动重连脚本

下面是核心脚本的整体结构，我把它命名为auto_network.py。整个脚本的逻辑是：主循环里先做网络检测，不通的时候根据当前网络类型决定是重连Wi-Fi还是直接认证，认证成功后继续监测。

import time import subprocess import requests import hashlib import logging # 配置日志系统 logging.basicConfig( filename="C:/auto_network/network.log", level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s", datefmt="%Y-%m-%d %H:%M:%S", ) # 账号配置 USERNAME = "你的学号" PASSWORD = "你的密码" LOGIN_URL = "http://xxx.xxx.xxx.xxx:801/eportal/portal/login" # 检测地址 CHECK_URL = "https://www.baidu.com" PING_TARGET = "223.5.5.5" # 阿里DNS，仅用来检测链路是否连通 def is_external_network_ok(): """检测外网是否连通""" try: resp = requests.get(CHECK_URL, timeout=3) return resp.status_code == 200 except Exception: return False def is_link_ok(): """检测网卡链路是否连通（能ping通即可）""" result = subprocess.run( ["ping", "-n", "1", "-w", "1000", PING_TARGET], capture_output=True, text=True, ) return result.returncode == 0 def do_authentication(): """执行校园网认证""" try: data = { "userId": USERNAME, "password": hashlib.md5(PASSWORD.encode()).hexdigest(), "service": "校园网服务标识", } resp = requests.post(LOGIN_URL, data=data, timeout=5) if "成功" in resp.text or "success" in resp.text.lower(): logging.info("认证成功") return True else: logging.warning(f"认证返回异常: {resp.text[:200]}") return False except Exception as e: logging.error(f"认证请求异常: {e}") return False def main(): logging.info("校园网自动连接脚本启动") fail_count = 0 while True: if is_external_network_ok(): # 外网正常，重置失败计数 fail_count = 0 else: # 外网不通，需要处理 fail_count += 1 logging.warning(f"检测到断网，第 {fail_count} 次尝试恢复") if is_link_ok(): # 链路正常但外网不通，直接认证 logging.info("链路正常，尝试重新认证") do_authentication() else: # 链路不通，尝试连接校园网Wi-Fi logging.info("链路异常，尝试重新连接Wi-Fi") subprocess.run(["netsh", "wlan", "connect", "name=JXUST-WiFi"]) # 等待Wi-Fi连接稳定后再认证 time.sleep(8) do_authentication() # 认证后等待几秒，让网络稳定 time.sleep(5) # 每次检测间隔5秒 time.sleep(5) if __name__ == "__main__": main()

这个脚本里面我用了日志系统，这是非常关键的一点。脚本在后台跑，如果出了问题你看不到报错，就无法排查。把所有关键动作写进日志文件，出问题的时候打开日志一看，马上就能定位。建议把日志文件路径放在一个专门创建的文件夹里，比如C:/auto_network/，方便管理。

4.3 为什么重连Wi-Fi用的是netsh命令

脚本里如果检测到链路不通，会执行netsh wlan connect命令来重新连接Wi-Fi。这里用的是Windows自带的网络管理工具，不需要安装任何第三方软件。命令格式是：

netsh wlan connect name=无线网络名称

这里的“name”填的是你电脑里保存的Wi-Fi配置名称，不一定是校园网Wi-Fi的实际SSID。怎么查？在命令行里输入netsh wlan show profiles，会列出所有已经保存的Wi-Fi配置，找到校园网对应的那个名字填进去就行。

为什么不直接网络适配器禁用再启用？如果你试过就会发现，重启网卡虽然能强制重新获取IP地址，但代价是要等十几秒甚至更久，音频、蓝牙等关联设备也会受影响。netsh命令只是重新触发无线连接，速度更快，副作用更小。

4.4 一个容易踩的坑：认证失败次数限制

有些校园网认证系统有防暴力破解机制，短时间内多次提交错误密码会被锁定一段时间。所以脚本里绝对不能写成“只要断网就疯狂重试”的死循环，必须加上重试间隔和失败计数。我的做法是：每次认证失败后等待至少10秒再进入下一轮检测，连续失败超过5次就停止认证，只在日志里记录，等半小时后再恢复尝试。这段逻辑你可以根据自己的情况调整，但一定要有这个保护机制。

5. 让脚本开机自启：Windows计划任务配置全流程

5.1 计划任务比启动文件夹更可靠

Windows下让程序开机自启有几种方式：放在启动文件夹里、写注册表Run键、创建计划任务。如果你试过把程序放进启动文件夹，会发现在校园网场景下这个方案有个致命问题：启动文件夹里的程序需要在用户登录后才能运行，而且如果程序闪退，没有任何机制帮你重新拉起来。

计划任务就不一样了。它由Windows系统服务管理，可以配置为“计算机启动时运行”，即使还没登录桌面也能启动。配合“如果任务失败则重新启动”的策略，哪怕脚本进程意外退出，系统也会自动把它重新拉起来。做后台守护类任务，计划任务是首选，没有之一。

5.2 创建计划任务的详细步骤

打开计划任务程序的方式很简单：按Win键，输入“任务计划程序”，回车打开。然后在右侧操作栏点击“创建任务”，依次配置：

常规选项卡：名称填“CampusAutoNetwork”，无论用户是否登录都要运行勾上，使用最高权限运行也要勾上。这里有个小细节，如果脚本要执行netsh之类的网络命令，普通权限可能不够，所以必须勾最高权限。

触发器选项卡：点击“新建”，开始任务选择“启动时”，也就是系统开机那一刻触发。如果担心断电后重启开机时间太早、网络服务还没准备好，可以在高级设置里设置“延迟任务时间”，我设的是30秒，给网卡和DHCP一点启动时间。

操作选项卡：点击“新建”，操作选择“启动程序”。程序或脚本填pythonw.exe的完整路径，一般位于C:\Windows\py.exe或者你自定义的Python安装目录里。参数填auto_network.py的完整路径，起始于填脚本所在目录。

条件选项卡：取消勾选“只有在计算机使用交流电源时才启动此任务”（宿舍台式机无所谓，但笔记本必须取消，否则拔了电源脚本就不跑了）。取消勾选“启动仅当网络连接可用时”，这个任务本身就是为了处理网络问题，不能依赖网络条件。

设置选项卡：勾选“如果任务失败，按以下频率重新启动”，频率选“1分钟后”，最多尝试次数填“99”。再勾选“如果任务结束时间已过，则按需启动”。

点确定保存，需要输入一下当前Windows登录密码。保存完成之后，任务计划里就多了一条开机自启任务。

5.3 用pythonw.exe而不是python.exe运行

这一点特别重要。Python在Windows下有两种可执行文件：python.exe和pythonw.exe。区别在于python.exe运行时会弹出黑色的控制台窗口，而pythonw.exe不会。后台运行脚本当然要用pythonw.exe，不然每次开机弹个黑框，关机都关不干净。

如果你安装Python时没有勾选“Add python.exe to PATH”，没关系，在任务计划里直接用完整路径。在命令行里输入where pythonw就能查到完整路径，一般长这样：C:\Users\你的用户名\AppData\Local\Programs\Python\Python311\pythonw.exe。填任务计划的时候最好直接用完整路径，避免环境变量出错导致任务起不来。

5.4 顺手把Wi-Fi自动连接也配置上

脚本里有链路检测和自动连接Wi-Fi的逻辑，但Windows本身也有一个Wi-Fi自动连接的设置，最好手动确认一下：进入设置——网络和Internet——WLAN——管理已知网络，找到校园网，确认“自动连接”开关是打开的。这样的话开机之后系统会先自动连上校园网Wi-Fi，然后脚本再完成认证，链路更顺滑。

这里还有个进阶技巧，在命令行里执行以下命令，可以设置校园网Wi-Fi为“优先连接”，在某些信号干扰严重的宿舍，系统会自动连到信号更强的其他网络，导致脚本里的名称匹配不上。强制优先校园网可以避免这种问题：

netsh wlan set profileorder name="校园网SSID" interface="WLAN" priority=1

6. 实测效果与问题排查实录

6.1 模拟场景测试

整套配置完成之后，我做了几个场景测试，确认脚本真的能用，而不只是“理论上能用”。

测试一：冷启动。电脑完全关机后重新开机，在未登录Windows的情况下等待60秒，然后登录桌面。检查日志文件，可以看到脚本在开机后约40秒自动运行，完成网络检测和认证，日志记录了“认证成功”。网络已经可用，不需要手动操作。

测试二：认证过期。登录校园网后台，把当前在线设备踢下线（模拟认证过期场景）。大约10秒后日志出现“检测到断网，第1次尝试恢复”，然后“链路正常，尝试重新认证”，再等几秒“认证成功”，网络自动恢复。

测试三：Wi-Fi断开。禁用Wi-Fi网卡再启用（模拟链路断开）。日志显示链路异常，触发netsh命令重新连接Wi-Fi，8秒后重新认证，恢复联网。整个恢复过程在20秒左右。

6.2 常见问题排查表

6.3 脚本更新与学校网络调整

这里要提醒一下，校园网认证系统如果哪天改版了、认证地址变了，脚本就不会生效了。别慌，处理方式很简单：重新走一遍“抓包——更新接口地址——更新参数格式”的流程，改一下脚本里的配置部分，重新保存即可。

为了防止改完脚本忘了备份又改坏了，建议把原始脚本复制一份存成auto_network_backup.py。反正脚本本身就是纯文本，放一个备份在U盘里或者邮箱里，出问题随时恢复。

6.4 安全与合规提醒

关于账号密码的保存，脚本里是明文存储的。所以这个脚本一定不要随便发给别人看，也不要传到网上的公开仓库里。自己的电脑如果设置了开机密码，文件放在用户目录下，安全性基本可控。但我还是建议，如果学校支持修改密码，周期性地更换密码，安全系数更高。

另一个重要提醒：这套方案只是让你自己的电脑上网更方便，不要用它来做共享网络、绕过校园网计费等操作。学校对在线设备数有明确规定，多设备同时登录可能导致账号被锁定，这就得不偿失了。脚本里也不需要写入多个账号轮流认证的逻辑，老老实实一个账号一个人用。

7. 一点额外的经验之谈

折腾这个方案的过程中，我最大的感悟是：校园网自动化的难点不在代码，而在对环境和机制的了解。你不需要多高深的编程水平，但你必须懂你的学校网络是怎么认证的，认证页面长什么样，请求参数怎么构造，什么时候需要认证而不是重启网卡。把这些搞清楚了，脚本写起来其实非常简单。

我个人的习惯是，每次脚本改动之后都会在日志里记录一行“配置更新”，这样之后如果出问题，回看日志就能知道是哪次改动引起的。另外，把整套文档和脚本打包放到一个文件夹里，标注好日期和版本号，下次电脑重装系统的时候，直接照着文档重新部署一遍，几分钟就搞定，不用重新踩坑。

这套方案我用了两个多月了，从春天用到入夏，除了学校晚间统一断电断网之外，没有遇到过需要我手动操作的场景。每天早上到教室打开电脑，网络已经在线；游戏中途掉线，十几秒后自动恢复；抢课的时候再也不用担心认证页面打不开。校园网依然会有它的脾气，但至少，它已经没办法再折磨我了。

如果这篇教程帮你省下了开学季排长队调试网络的时间，或者让你在某个关键的抢课夜晚保住了心态，那我觉得这些天折腾脚本的深夜，就完全值了。