“校园网连上了但没网”这八个字，几乎是每个新学期都会被反复提起的老问题。笔记本右下角Wi-Fi图标亮着，信号满格，认证客户端也显示登录成功，可浏览器一打开就是“正在加载”或者“无法访问此网站”。这时候总会有人丢过来一句：在地址栏里敲1.1.1.1试试。说实话，这个方法我第一次听到时也半信半疑，后来在宿舍、实验室、图书馆自习区来回折腾了几年，才明白它不是什么玄学偏方，而是一个非常好用的网络分层排查入口。它真正解决的不是“没网”这个模糊描述，而是帮你判断“到底是哪一层没通”。这篇内容就把这件事讲透：1.1.1.1 是什么、为什么输入它就能看出问题、校园网这种特殊环境里该怎么一步步排查、哪些坑我亲自踩过。不管你是刚入学的新生，还是被室友喊去“看看网”的半吊子技术担当，都能照着做。
1. 先别急着重启：把“连上但没网”拆成四层来看
1.1 从Wi-Fi图标到网页加载，中间隔着四道关卡
很多人对“联网”的理解是一条线：连上Wi-Fi就等于能上网。实际不是。从你点开浏览器到页面出现，中间至少隔着四道关卡，任何一道卡住，表现都是“没网”，但病因完全不同。
第一道是链路层，也就是无线网卡和接入点之间有没有建立连接。Wi-Fi图标亮着、显示“已连接”，只说明这一层通了。第二道是网络层，设备有没有拿到合法的IP地址、子网掩码、默认网关，这一步靠DHCP完成。第三道是认证层，校园网通常会有Portal页面认证或者专用客户端认证，没通过认证的设备，即使拿到了IP，流量也会被网关拦下来。第四道才是应用层，包括DNS解析、TCP连接、TLS握手、HTTP请求。
我见过太多人一上来就改DNS、换浏览器、重装系统，结果问题其实卡在第二层——设备拿的是一个169.254开头的自动私有地址，网关根本没分配成功。这种情况下你把DNS改成什么地址都没用，因为数据包连小区门都出不去。所以排查的第一步不是动手改，而是先确认自己卡在哪一层。这个思路听起来朴素，但能省掉大量无效操作。
1.2 浏览器里输入IP，为什么能当“听诊器”用
平时我们访问网站，输入的是域名，比如某个学习平台的名字。浏览器拿到域名后，第一件事是找DNS服务器问：“这个域名对应的IP是多少？”拿到IP之后，才去跟那台服务器建立连接。也就是说，域名访问天然依赖DNS，而IP访问不需要。
这就是输入1.1.1.1的价值所在。它相当于做了一次对照实验：如果域名打不开，但直接输入IP能打开页面，说明你的网络链路是通的，问题大概率出在DNS解析上；如果连IP都打不开，那问题就更靠下，可能是网关、认证、路由或者设备本身。这个判断只需要十秒钟，却能把排查范围砍掉一半。
我习惯把这个过程叫作“听诊”：不急着开药，先用一个最简单的动作听听哪里没有声音。很多网络问题之所以越修越乱，就是因为跳过了诊断直接动手，改了一堆设置，最后连最初的现象都复现不了了。
1.3 一个容易被误判的现象：认证页没弹出来
校园网还有一个特别常见的坑：认证页面没有自动弹出。设备明明连上了Wi-Fi，IP也拿到了，但打开浏览器输入任何地址都转圈，既不跳认证页，也不报明确错误。很多人以为这是“没网”，其实是认证流程被拦住了。
常见原因有这么几类：浏览器把认证页当成弹窗拦截了；系统里之前配置过某个中转服务器或者Hosts记录，导致认证域名被解析到了错误地址；设备时间与网络时间偏差太大，证书校验失败；还有些安全软件会接管浏览器的首屏请求，把跳转逻辑吃掉。
判断方法很简单：手动在地址栏输入一个常见的认证入口地址，或者输入一个纯IP的页面看看有没有反应。如果IP能打开、域名跳转失败，基本可以锁定是解析或者拦截问题，而不是链路问题。这一步和1.1.1.1的对照实验是互补的，一个看“通不通”，一个看“跳不跳”。
2. 1.1.1.1 这个地址到底管什么用
2.1 DNS是互联网的“电话簿”，不是“网线”
很多人把DNS和网络连接混为一谈，觉得“DNS坏了就是断网了”。准确地说，DNS只是一本电话簿：你报一个名字，它告诉你对应的号码。电话簿丢了，你打不了电话，但电话线本身可能是好的。
DNS服务器的工作就是接收域名查询，返回IP地址。这个查询过程通常是递归的：你的设备问本地DNS，本地DNS如果不知道，就往上问，直到拿到结果再层层返回。校园网里的DNS服务器一般由网络中心统一提供，通过DHCP自动下发给设备。它的优点是离你近、解析校内资源快；缺点是如果它本身出故障、被限流，或者配置出了偏差，你所有依赖域名的访问都会卡住，但IP直连却正常。
这也是为什么“改DNS”成了民间最流行的网络偏方。它确实能解决一部分问题，但只对DNS解析故障有效。如果问题是网关不通、认证没过，改DNS就是白忙活。我在宿舍见过有人把DNS改了三遍，最后发现是网线松了，这种事说出来好笑，但当时当事人是真的急。
2.2 为什么DNS出问题时，输入IP反而能打开网页
假设你访问一个学习资源站，域名解析被卡住了，浏览器一直停在“正在解析主机”。这时候你在地址栏输入1.1.1.1，浏览器不需要问DNS“1.1.1.1是谁”，因为它本身就是IP。它会直接向这个地址发起连接，走的是同一套网关、同一套路由。
如果这个页面能打开，说明你的设备到公网的路由是通的，认证大概率也过了，问题就锁定在域名解析环节。这时候再去检查DNS服务器地址、清缓存、换一个公共DNS，方向就非常明确。
如果这个页面打不开，也不代表世界末日。继续往下分：能不能ping通网关？能不能打开校内的某个IP页面？如果校内IP能开、校外IP不能开，那可能是认证或者出口策略问题；如果连网关都ping不通，那就是本地链路或者IP配置问题。一层一层剥，比盲目重启有效得多。
2.3 几个常见公共DNS地址与选择思路
公共DNS的作用是给你提供一个备用的解析入口。下面这几个地址在排查时经常被用到，我列出来只是为了方便你做对照实验，不涉及任何推荐排序。
| 地址 | 常见用途 | 特点说明 |
|---|---|---|
| 1.1.1.1 | 公共解析 | 响应快，适合做连通性对照 |
| 8.8.8.8 | 公共解析 | 老牌地址，覆盖面广 |
| 223.5.5.5 | 公共解析 | 国内访问延迟通常较低 |
| 119.29.29.29 | 公共解析 | 常用备选之一 |
| 114.114.114.114 | 公共解析 | 普及度高，记忆方便 |
选择的时候不用纠结“哪个最好”，因为不同网络环境下的表现差异很大。我的做法是：主DNS保留校园网自动下发的地址，备用DNS填一个公共地址。这样既不影响校内资源解析，又能在主DNS出问题时有一个兜底。注意，备用DNS不是自动故障转移的万能药，很多系统只有在主DNS超时后才会尝试备用，所以它更像保险丝，不是加速器。
提示：修改DNS之前，先把原来的地址记下来或者截图。校园网环境里，有些校内站点只认校内DNS，改完忘了改回去，后面访问图书馆资源、内部系统时又会出问题。
3. 完整实操：从输入地址到恢复上网的五步排查法
3.1 第一步：用IP直连做一次对照实验
打开浏览器，在地址栏输入1.1.1.1，回车。注意是地址栏，不是搜索框。如果你用的是某些会把地址栏输入当搜索词的浏览器，记得在地址前面加上http://，避免它把IP当成关键词去搜索。
观察结果，分三种情况：
- 页面能打开：说明链路、网关、认证基本正常，重点查DNS。
- 页面打不开但很快报错：记下报错类型，比如“连接超时”“无法访问此网站”“ERR_CONNECTION_REFUSED”，不同报错指向不同环节。
- 一直转圈没有结果：更像是网关不通或者流量被拦截。
这一步不需要任何工具，三十秒内就能完成。我建议你把这个动作养成习惯，遇到“没网”先做对照，再决定往哪个方向修。
3.2 第二步：检查网关和IP地址是不是“假在线”
Windows上打开命令提示符，输入：
ipconfig /all重点看三个信息：IPv4地址、默认网关、DHCP服务器。如果IPv4地址是169.254开头，说明DHCP没拿到地址，设备在自我分配，这种情况几乎可以肯定上不了网。如果默认网关为空，路由表不完整，同样出不去。
接着测试网关连通性：
ping 你的默认网关地址比如网关是192.168.1.1，就ping这个地址。能通说明本地链路没问题；不通说明无线连接、网卡驱动或者接入点侧有问题。再测试一个公网IP：
ping 1.1.1.1能ping通但网页打不开，问题可能在DNS或者应用层；ping不通但网关能通，问题可能在认证或者出口策略。
macOS和Linux用户可以用ifconfig或ip addr查看地址，用netstat -rn查看路由表。命令不同，思路一样：先确认自己有没有合法身份，再确认能不能走到门口。
3.3 第三步：改DNS的具体操作
确认是DNS问题之后，再动手改。不同系统的入口不一样，我按常用平台分别说。
Windows：打开“网络和Internet设置”，进入“更改适配器选项”，右键当前使用的无线或有线连接，选择“属性”，双击“Internet协议版本4”，选择“使用下面的DNS服务器地址”，主DNS填校园网原来的地址或者留空，备用DNS填一个公共地址。保存后建议执行一次：
ipconfig /flushdnsmacOS：进入“系统设置”里的网络，选中当前连接，点“详细信息”，切到“DNS”标签页，用加号添加地址。改完后同样建议清一次缓存：
sudo dscacheutil -flushcacheAndroid和iOS：移动端一般不直接暴露DNS设置，需要在Wi-Fi详情里找“配置DNS”或者“私有DNS”选项。如果系统版本不支持，就别硬改，优先在电脑上排查，或者用浏览器自带的诊断页面看解析状态。
改完之后，重新访问一个域名站点测试。如果域名能打开、IP也能打开，说明问题解决；如果IP能打开、域名还是不行，检查是不是浏览器缓存或者Hosts文件在作怪。
3.4 第四步：清缓存、换浏览器、看时间
DNS缓存分好几层：系统缓存、浏览器缓存、路由器缓存。系统缓存清过了，浏览器这一层也别漏。大多数浏览器都有“清除浏览数据”的入口，选择“缓存的图片和文件”即可，不用把密码和历史记录一起清掉。
换一个浏览器测试也是快速排除法。如果A浏览器打不开、B浏览器能打开，问题大概率在A浏览器的扩展、缓存或者安全设置上。我遇到过某款插件接管了所有请求，把特定域名指向了本地地址，表现就是“别的网站都能开，就它不行”。
还有一个特别容易被忽略的点：系统时间。时间偏差太大会导致HTTPS证书校验失败，浏览器会直接拦截页面，报“证书无效”或者“连接不是私密连接”。很多人看到这个报错以为是网络问题，其实是时间跑偏了。把系统时间设为自动同步，重启浏览器再试，往往就好了。
3.5 第五步：处理认证门户与安全软件拦截
如果IP能通、域名也能解析，但网页就是打不开，或者总是跳到奇怪页面，就要看认证和安全软件了。
校园网的认证方式通常有三种：网页Portal认证、专用客户端认证、MAC地址绑定。Portal认证最容易被浏览器拦截，可以尝试手动输入认证入口地址，或者换一个不常用的浏览器，关闭弹窗拦截。专用客户端认证则要注意客户端版本和系统兼容性，有些旧版本在新系统上会显示“已登录”但实际没通过。
安全软件方面，某些防火墙或者流量管理工具会接管浏览器的首屏请求，导致跳转失败。排查时可以临时退出这类软件，再试一次。如果退出后恢复正常，就去软件设置里把认证域名加入白名单，而不是一直关着不用。
注意：排查过程中尽量不要同时改多个设置。一次只动一个变量，改完测一次，不行就改回去。否则最后问题解决了，你也不知道是哪一步起的作用，下次再遇到还是一头雾水。
4. 现象对照表：不同报错对应不同病因
4.1 常见现象与处理速查
网络排查最怕“症状描述模糊”。下面这张表是我自己整理的对照速查，把常见现象和大概率病因放在一起，方便你快速定位。
| 现象 | 大概率病因 | 优先处理 |
|---|---|---|
| Wi-Fi显示已连接，IP是169.254开头 | DHCP未分配地址 | 重连、重启网卡、检查接入点 |
| 能ping通网关，ping不通公网IP | 认证未通过或出口策略限制 | 检查认证状态、重新登录 |
| 能ping通公网IP，域名打不开 | DNS解析故障 | 改DNS、清缓存 |
| 输入1.1.1.1能开，其他域名全挂 | DNS问题概率高 | 对照实验、换DNS |
| 输入1.1.1.1也打不开，但校内IP能开 | 出口或认证问题 | 检查认证客户端 |
| 页面提示证书错误 | 系统时间偏差或拦截 | 校准时间、检查拦截软件 |
| 只有某个网站打不开 | 该站点自身故障或本地Hosts | 换设备测试、检查Hosts |
| 认证页不弹出 | 浏览器拦截或解析异常 | 手动输入认证地址、换浏览器 |
这张表不是万能答案，但它能帮你把“没网”翻译成更具体的问题。排查的本质就是不断缩小范围，而不是一次性猜中答案。
4.2 IPv6、DoH、多网卡这些隐藏变量
现在的网络环境比以前复杂，几个隐藏变量经常把人带偏。
IPv6优先：有些系统会优先走IPv6，如果校园网的IPv6出口没有配置好，而域名又解析出了AAAA记录，浏览器就会先尝试IPv6，超时后再回退到IPv4。表现就是“打开很慢，但最终能开”或者“时好时坏”。排查时可以在系统设置里临时关闭IPv6，看看现象是否消失。
加密DNS：部分浏览器和系统默认开启了加密DNS，查询不走本地下发的DNS服务器，而是走内置的解析通道。这在公共网络里是好事，但在校园网里可能导致校内域名解析不到。表现是校外网站正常、校内资源打不开。遇到这种情况，去浏览器设置里关闭“安全DNS”或者改为“使用当前服务提供商”。
多网卡冲突：笔记本同时开着Wi-Fi和有线，或者装了虚拟网卡、容器工具，路由表里可能出现多条默认路由，流量走了错误的那条。用route print或者netstat -rn看一下默认路由指向哪个接口，心里就有数了。
4.3 排查顺序的经验：先近后远、先软后硬
我自己的排查顺序基本固定：先看IP和网关，再看认证，再看DNS，最后看应用层。这个顺序的好处是每一步都能独立验证，不会互相干扰。
“先近后远”指的是先查自己设备到接入点这一段，再查接入点到出口那一段。“先软后硬”指的是先查配置、缓存、认证状态，再考虑网卡驱动、硬件故障。因为绝大多数问题出在配置层，硬件故障反而是小概率事件。
还有一条经验：别在问题现场做不可逆操作。比如重装网卡驱动、重置网络设置、删除所有配置文件，这些操作一旦做了，问题没解决反而增加了新的变量。先把能恢复原状的设置改一遍，确认无效再考虑大动作。
5. 踩坑实录：几个典型场景下的排查过程
5.1 场景一：IP能开，域名全挂
某同学反映，宿舍Wi-Fi连上了，认证也过了，但除了少数几个App，网页几乎全打不开。我让他输入1.1.1.1，页面秒开。这一下就基本锁定DNS了。
接着看他的DNS配置，发现主DNS和备用DNS都被手动改成了同一个地址，而且那个地址在当前网络里响应很慢。恢复成自动获取之后，域名访问恢复正常。问题不在于公共DNS不好，而在于他改完之后没有测试，也没有记下原来的配置，导致后面几天一直以为是“校园网抽风”。
这个场景的教训很直接：改DNS可以，但要保留回退路径。最好把原地址截图，或者干脆用“自动获取”作为主方案，只在排查时临时指定。
5.2 场景二：改了DNS，第二天又失效
另一个常见情况是，改完DNS当天好了，第二天连上网络又不行了。原因通常有两个：一是系统里有多个网络配置文件，改的只是其中一个，切换网络后生效的是另一套配置；二是某些认证客户端或者管理软件会在登录时重置网络设置，把你手动改的DNS覆盖掉。
处理办法是检查所有相关网络配置，包括当前连接、备用连接、虚拟网卡。如果确认是客户端覆盖，就不要跟它对抗，改用自动获取，把排查重点放回认证和网关。很多时候，DNS只是背了锅，真正的问题是认证客户端在后台反复重连，导致网络状态不稳定。
5.3 场景三：客户端显示已登录，网页还是转圈
某实验室的公用电脑，认证客户端显示“已登录”，但浏览器打开任何页面都转圈。IP配置正常，网关能ping通，1.1.1.1也能打开，就是域名不行。
最后发现是Hosts文件里残留了一条旧记录，把认证域名指向了一个已经不存在的地址。清理Hosts之后恢复正常。这个问题的隐蔽性在于，它不影响IP访问，只影响特定域名，表现非常像DNS故障，但改DNS没用。
Hosts文件的位置：Windows在C:\Windows\System32\drivers\etc\hosts，macOS和Linux在/etc/hosts。排查时可以用文本编辑器打开看看有没有异常条目，尤其是那些你完全没印象的域名。
提示：修改Hosts需要管理员权限，改之前先备份。排查完把临时加的条目删掉，不要留着，否则下次网络变动时又会出问题。
6. 把这些设置固化成习惯
6.1 备用DNS的配置策略
我不建议把公共DNS设成主DNS，尤其是在校园网环境里。校内资源、认证页面、图书馆系统往往依赖校内解析，主DNS改成公共地址后，这些资源可能解析不到或者绕远路。更稳妥的做法是：主DNS用自动获取，备用DNS填一个公共地址作为兜底。
如果你经常在不同网络之间切换，可以给每个网络单独保存配置，而不是全局改。Windows的网络配置文件、macOS的“位置”功能都支持这套逻辑。多花两分钟配置，能省掉以后很多次“怎么又没网了”的困惑。
6.2 记录一份自己的网络排查清单
我现在习惯在备忘录里放一份简短的排查清单，遇到问题时按顺序过一遍：
- 看IP是不是169.254开头，是就重连或查DHCP。
- ping网关，确认本地链路。
- ping 1.1.1.1，确认出口。
- 输入1.1.1.1做对照实验，判断DNS。
- 检查认证状态和客户端。
- 清DNS缓存、换浏览器、看系统时间。
- 检查Hosts、加密DNS、多网卡路由。
这份清单不复杂，但能覆盖八成以上的常见问题。真正复杂的故障还是得靠专业工具抓包分析，但对日常使用来说，按顺序排除已经足够。
最后分享一个我个人踩坑后养成的习惯：每次帮别人处理完网络问题，都把改过的设置记一笔，改回去了哪些、保留了哪些。因为最容易出问题的不是“不会修”，而是“修完之后忘了自己动过什么”。网络设置这东西，改的时候觉得清清楚楚，过两周就忘得一干二净，等下次出问题，面对一堆非默认配置，排查成本反而更高。把1.1.1.1当成一个诊断入口，而不是一个万能答案，很多问题会变得清晰得多。
