网络基础回顾：DNS、IP封锁与HTTP/S协议关键点

网络基础回顾DNS、IP封锁与HTTP/S协议关键点昨天有个读者在后台问我“为什么改了Hosts文件还是打不开ZLibrary明明Ping得通啊。” 这个问题让我想起刚入行时踩过的坑——你以为网络通了其实只是你以为。今天我们就从这个问题切入把DNS、IP封锁和HTTP/S这几个基础但容易误解的概念拆开揉碎了讲清楚。一、DNS你以为的“域名解析”可能只是缓存把戏很多人以为改了Hosts文件就万事大吉其实Hosts只是本地DNS解析的第一站。系统在查Hosts之后还可能走DNS缓存、本地DNS服务器、公共DNS比如8.8.8.8这一整套流程。我遇到过最诡异的情况是Hosts改对了但浏览器死活不认最后发现是DNS-over-HTTPSDoH在作祟——现代浏览器默认开启DoH时会绕过系统的DNS解析机制。# 查看本地DNS缓存Windowsipconfig /displaydns# 清空它有时候缓存比想象中顽固ipconfig /flushdns踩坑提醒别以为Hosts是万能的浏览器插件、VPN客户端、甚至某些安全软件都可能劫持DNS请求。调试时最好先用nslookup或dig验证真实解析结果nslookupz-lib.is8.8.8.8# 如果返回的IP不是你Hosts里写的说明请求被劫持了二、IP封锁TCP握手背后的沉默杀戮“Ping得通但网页打不开”——这是典型的IP封锁场景。Ping走的是ICMP协议而网页访问走的是TCP协议。运营商或防火墙可以只封TCP端口而放过ICMP让你产生“网络是通的”错觉。# 简单测试TCP端口是否可达Python示例importsocket socksocket.socket(socket.AF_INET,socket.SOCK_STREAM)sock.settimeout(3)try:# 测试443端口这里经常是封锁重点sock.connect((目标IP,443))print(TCP握手成功)exceptExceptionase:print(f连接被掐了:{e})finally:sock.close()更隐蔽的封锁是TCP RST攻击你的SYN包能出去对方也回了SYN-ACK但中途被防火墙伪造RST包强行中断握手。抓包看Wireshark会看到一串“TCP Spurious Retransmission”警告这时候就得考虑用隧道或加密混淆把TCP流量藏起来。三、HTTP/S协议中间人就在你身边即使DNS和IP层都通了应用层还有一道关卡HTTPS拦截。有些防火墙会做SSL中间人检测通过证书指纹或SNIServer Name Indication识别并阻断敏感网站。# 用curl测试HTTPS连接注意--resolve参数绕过DNScurl-v--resolvez-lib.is:443:真实IP https://z-lib.is# 如果卡在SSL握手可能是SNI被盯上了关键点SNI是TLS握手时明文发送的域名信息防火墙看一眼就知道你要访问什么网站。应对方案有两种一是用ESNIEncrypted SNI但普及度不高二是把流量套在WebSocket或HTTP/2 Stream里伪装成普通网站流量。不过要注意别随便在代码里关证书验证verifyFalse那种写法除非你清楚自己在做什么——中间人攻击真不是闹着玩的。四、实战调试心法分层排查从底层往上层撸。先ping再telnet IP 端口测TCP然后curl -I看HTTP响应头最后上浏览器。很多问题在第二步就现原形了。善用本地代理工具Charles、Fiddler这类工具能帮你看到HTTPS解密后的流量需安装信任证书有时候封锁规则就藏在HTTP头部的X-Blocked-By字段里。不要相信单一检测手段Ping通不代表TCP通TCP通不代表TLS握手成功TLS通了还可能遇到HTTP 451状态码法律原因不可访问。多维度验证才靠谱。写在最后网络封锁的本质是一场不对称战争防守方占据协议栈的每个层级进攻方则要在夹缝里找生机。我的经验是越底层的绕过越稳定但实现越复杂越高层的方案越灵活但也越容易失效。调试时保持耐心一次只动一个变量记住那句老话“它能在curl里工作吗如果能那就不是网络问题是你的代码问题。”下次我们聊具体的技术方案如何用域名前置、SNI伪装和隧道技术让请求“看起来像别的请求”。保持好奇保持折腾。专栏预告003、隧道技术入门SSH、Cloudflare Tunnel与反向代理实战