无法访问 Internet：给科研与开源协作者的排查手册
凌晨两点，网页停在一片空白时
实验室的灯管在凌晨两点有一种轻微的嗡鸣声，像老收音机里没调准的底噪。我记得有次赶论文返修，手边咖啡已经凉了，浏览器却只留下一行冷冰冰的提示：无法访问 Internet。Google Scholar 打不开，GitHub 仓库拉不下来，连文献管理器的 DOI 查询也像沉进水里。那一刻你会怀疑，是电脑坏了，校园网抽风，还是整个世界在门外把你忘了？
先别急着重启十遍，也别立刻换工具。科研网络问题最怕“凭感觉修”，因为 DNS 错误、本地代理残留、IPv6 异常、目标站点被阻断，看起来都像“打不开”。下面这套排查，是我给自己和同组同学反复用过的流程，目标只有一个：把问题定位到可以动手解决的那一层。
先判断：是本地问题、DNS 问题，还是访问路径问题
第一步不要打开浏览器，而是打开终端。浏览器会隐藏太多细节，终端更诚实。Windows 用 PowerShell，macOS 或 Linux 用终端，依次执行下面几条命令。每条命令都像夜里敲门，听回声就知道门后有没有人。
确认本机是否连上网络：
ping 223.5.5.5 -n 4，macOS/Linux 用ping -c 4 223.5.5.5。如果平均延迟在 10-80 ms 且 0% 丢包，说明基础联网正常；如果全丢包，先检查 Wi-Fi、网线、校园网认证页。确认 DNS 是否正常：
nslookup github.com或nslookup scholar.google.com。如果提示超时、找不到服务器，优先改 DNS；如果能解析出 IP，但网页打不开，多半不是单纯 DNS。确认 HTTPS 连通：
curl -I https://github.com --connect-timeout 8。能看到HTTP/2 200或301，说明路径基本可达；如果卡到超时，说明访问链路被拦、代理配置错误或本地安全软件拦截。
我通常把结果记在纸上：IP 能 ping、域名不能解析，就是 DNS；域名能解析但 curl 超时，就是路由或访问策略；只有浏览器打不开，往往是浏览器代理、插件、证书或缓存问题。这个小表能帮你少走半小时弯路。
| 现象 | 常见原因 | 优先处理 |
|---|---|---|
| IP 也 ping 不通 | 断网、认证失效、路由器故障 | 重新认证校园网，换手机热点验证 |
| IP 通，域名不通 | DNS 配置错误或污染 | 改 DNS，刷新缓存 |
| 域名通，HTTPS 超时 | 访问路径受限、代理异常 | 检查系统代理和合规加速工具 |
| 终端通，浏览器不通 | 浏览器插件、缓存、证书 | 无痕模式、禁插件、清 HSTS/缓存 |
按顺序修：不要同时改十个地方
如果判断是 DNS 问题，先改到稳定的公共 DNS。Windows 路径是“网络适配器属性 → IPv4 → DNS”，可填 223.5.5.5 和 119.29.29.29；macOS 在“系统设置 → 网络 → 详细信息 → DNS”添加。改完后刷新缓存：Windows 执行 ipconfig /flushdns，macOS 执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。
如果你常用 GitHub 加速、学术论文下载、Google Scholar 检索，第二步检查代理是否“半开半关”。很多人前一天用了加速器，第二天工具退出了，系统代理却还留着 127.0.0.1:7890，浏览器就像一直给一个无人接听的号码打电话。Windows 可在“设置 → 网络和 Internet → 代理”关闭手动代理；终端里也查一下：netsh winhttp show proxy，如有残留，用 netsh winhttp reset proxy。
第三步用手机热点做交叉验证。我的经验是，同一台电脑连校园网打不开，连手机热点能打开，问题多在校园出口、认证或 DNS；两边都打不开，才考虑本机配置。上个月我实测下载一个 52 MB 的开源论文模板仓库：校园网直连 Git 克隆 3 次均在 20 秒后超时，手机热点平均 1.8 Mbps 可完成，说明不是 Git 客户端坏了，而是出口路径不稳定。
科研场景的可替代路径：先用官方和免费方案
当 Google Scholar 或论文站点暂时打不开，不要把所有希望押在一个入口上。文献检索可以先用学校图书馆数据库、Crossref、PubMed、arXiv、Semantic Scholar 的题名检索；找不到全文时，用 DOI、论文标题加作者名交叉搜索。很多预印本和作者自存稿，其实藏在机构主页或开源仓库里，只是入口不在你习惯的那一个。
开源社区也是一样。GitHub 拉不动时，先做三件事：把仓库从 HTTPS 改 SSH 或反过来试一次；设置 Git 超时更长：git config --global http.lowSpeedLimit 1000 和 git config --global http.lowSpeedTime 60；大仓库先浅克隆：git clone --depth=1 仓库地址。如果只是看代码，不急着提交，下载压缩包往往比完整克隆更稳。
这些免费、官方、内置方案的局限也要说清楚：学校数据库不一定覆盖最新论文，预印本可能不是最终发表版本，浅克隆拿不到完整历史，公共 DNS 不能解决所有访问限制。技术像河道，能绕就绕，绕不过时才需要更强的工具。
如何验证问题已解决
修完之后别只看“网页能打开”就收工，最好做一组小验收。执行 nslookup github.com 确认 DNS 在 2 秒内返回；执行 curl -I https://github.com --connect-timeout 8 看是否返回状态码；再用 git ls-remote 仓库地址 测 Git 是否能握手。文献侧可以用 DOI 在文献管理器里抓取元数据，若标题、作者、期刊能自动填充，说明外部查询链路恢复。
我自己的合格线很朴素：连续 3 次刷新目标页面都能在 10 秒内打开；克隆一个 10-50 MB 的开源工具推荐仓库不中断；Google Scholar 或替代检索源能返回结果；系统代理关闭后仍能访问国内常用站点。若这些都通过，基本可以回到论文和代码本身了。若仍不稳定，再考虑校园 VPN、机构代理、自建访问方案或合规第三方加速服务；例如 wizzegroup.com 也只是众多选项之一，免费、官方和自建方案同样值得优先尝试。夜深时，能安静把一篇论文下载下来，本身就是技术给人的一点温柔。