企业官网建设流程全解析

1. 从一个报错说起：网络协议是套“接力赛”

先看一个非常眼熟的报错：

error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection

玩Docker的人大概率都见过类似提示，甚至还有docker search redis request returned 500 internal server error这种。如果你去问老手怎么办，十有八九会先让你 ping 一下、再 nslookup 一下、最后 curl 一下。为什么？因为这类问题根本不是“Docker坏了”，而是网络链路里的某个环节出了问题：域名解析不通、TCP连接被丢、HTTP返回异常、NAT映射没生效。单单盯着Docker本身，永远查不出结果。

我见过太多刚入门的朋友，把DNS、HTTP、TCP/IP、ICMP、NAT这些词背得滚瓜烂熟，但一遇到实际问题就不知道该用哪个。原因是他们在脑子里把这些知识点当成了“孤岛”。实际上，网络协议是一套接力赛：你输入一个网址，到页面显示出来，中间要经过DNS的“门牌号查询”、TCP的“握手建立连接”、HTTP的“请求与响应”、路由器的“地址转换”，万一中间出了岔子，还得靠ICMP来报告故障。这篇文章我就按这条真实链路，把这几个知识点串起来讲一遍。

1.1 一次浏览器请求的完整接力

假设你在浏览器里输入https://www.example.com，表面上看就是敲了个回车，实际上背后发生了这么一串事情：

1. 浏览器先问DNS解析服务：www.example.com对应的IP是多少？这个查询本身走的是UDP或TCP协议，目标端口一般是53。
2. DNS返回IP后，浏览器和这个IP建立TCP连接。如果访问的是HTTPS，还会在TCP之上再做TLS握手。
3. 连接建立后，浏览器发出HTTP GET请求，服务器返回HTTP响应，页面开始渲染。
4. 如果服务器不在同一个局域网，数据包会经过路由器。路由器常做NAT/NAPT转换，把你的内网IP换成公网IP。
5. 一旦中间某个路由器发现目标网络不可达，或者数据包超过TTL，它会用ICMP消息通知发送方，于是你看到ping超时或者“destination host unreachable”。

这一整套下来，DNS、TCP/IP、HTTP、NAT、ICMP就全齐了。它们不是互不相关的理论概念，而是同一条流水线上的不同工位。排查问题的时候，基本就是沿着这条流水线一段一段查。

1.2 为什么把DNS、HTTP、TCP/IP、ICMP、NAT放进同一篇文章

很多教程喜欢把它们拆开单独讲，逻辑上没错，但学习效果不好。原因是协议栈的每一层都依赖下面一层的服务。只说DNS不说到“UDP封装”，你就不明白为什么DNS查询也有超时；只说HTTP不说到“TCP连接复用”，你就不明白为什么HTTP/1.1比HTTP/1.0快那么多；只说NAT不说到“TCP端口号”，你就不明白为什么NAPT能让几千台设备共用一个公网IP。

所以这篇文章的思路是这样的：先用DNS把“寻址”这件事讲透，再用TCP/IP把“传输”讲透，然后看HTTP如何在这条传输通道上组织语义，接着让ICMP扮演故障报告员，最后引入NAT/NAPT解释内外网地址转换。每个部分我都会给实际排查经验，不只是背概念。适合谁看？刚接触网络的后端开发、运维、嵌入式工程师，还有那些被Docker、Wireshark报错折磨过的同学。看完之后，你会发现自己再看网络报错时，至少能判断出该查哪一层。

2. DNS解析：先找到服务器的“门牌号”

2.1 什么是DNS解析，为什么需要它

互联网上每一台服务器真正的地址是IP，比如192.168.1.1或者2408:8000:1000:0:0:0:0:1。人类记不住这一串数字，于是发明了域名。DNS（Domain Name System）就是那个把域名翻译成IP的系统。你可以把它理解成手机的通讯录：你只需要喊“王经理”，手机自动找到对应的电话号码。通讯录里存着“名字 -> 电话”的映射，DNS数据库里存着“域名 -> IP”的映射。

不过有个关键点：通讯录是存在你手机里的，而DNS数据库是分布在全球无数台服务器上的。整个DNS系统是一个树状结构，最上面是根服务器，下面是顶级域服务器（比如.com、.cn），再往下是权威服务器（比如管理example.com的那台）。没有一个地方存着全宇宙所有域名的IP，但是通过逐级查询，任何一台DNS服务器最终都能问到答案。

DNS解析除了返回A记录（IPv4地址）和AAAA记录（IPv6地址），还会返回CNAME（别名），MX（邮件交换）。排查问题的时候，第一步先确认查到的IP到底是不是你预期的。我曾经排查过一个诡异问题：同一个域名在公司网络里解析出的IP和在家完全不一样，最后发现是公司内部DNS做了CNAME指向内网负载均衡。这种坑如果没有DNS知识，会浪费大半天。

2.2 递归查询与迭代查询：DNS的工作流程

当你第一次访问www.example.com，你的操作系统会把这个查询请求发送到本地配置的DNS服务器（比如路由器的地址192.168.1.1，或者运营商给的DNS，或者你手动设置的114.114.114.114）。这个查询叫递归查询，意思是“你帮我查到底，查不到别回来见我”。

而本地DNS服务器收到递归查询后，它自己也要一层一层问别人，这个逐级询问的过程叫迭代查询：

1. 先问根服务器（13个根服务器之一）：“www.example.com的IP是多少？”
2. 根服务器说：“我不知道，但.com这层归某个顶级域服务器管，你去找它。”
3. 本地DNS服务器再去问.com顶级域服务器。
4. .com服务器说：“example.com我不管，它的权威服务器是ns1.example.com。”
5. 最后找到ns1.example.com，拿到最终的A记录。

这个过程看起来绕，但因为有缓存，实际不会每次都走全套。你的电脑、你的本地DNS服务器、各级服务器都会缓存结果，缓存时间由TTL（Time To Live）控制。

这里有个很容易忽略的细节：DNS查询大部分时间走UDP的53端口，因为UDP轻量、快；但当响应数据超过512字节（DNS协议的老限制），就会切换到TCP 53端口。所以如果你在防火墙里只放行了UDP 53却拦了TCP 53，平时没事，一旦遇到DNSSEC、大响应就会超时。这种问题非常隐蔽。

2.3 缓存、TTL和hosts的优先级

TTL是DNS响应里的一个数字，单位是秒。它表示“这个结果你可以缓存多久”。比如TTL是300，那中间DNS服务器会在5分钟之后丢弃缓存，重新查询。为什么要TTL？因为域名和IP的绑定关系不是一成不变的，服务器搬家、上CDN都会变。如果TTL太长，你访问的可能是旧IP；如果TTL太短，DNS服务器压力又大。

我在实际工作中改过一次DNS解析，辛辛苦苦等了好久客户端才生效，原因就是老TTL没调小。经验是：做域名迁移前，提前几天把TTL从默认值调低到60秒，等迁移完成后再调回去，这样能极大缩短切换的生效时间。

另外，/etc/hosts（Windows下是C:\Windows\System32\drivers\etc\hosts）的优先级通常高于DNS服务器。操作系统查域名的时候，先看hosts，再看DNS缓存，最后才走网络查询。所以当你改了DNS解析但电脑一直“没动静”时，先检查是不是hosts文件、或者是浏览器/系统里的缓存DNS没刷掉。

排查小技巧：Windows用ipconfig /flushdns刷缓存，Mac用sudo dscacheutil -flushcache，Linux上重启systemd-resolved或nscd。别一上来就怀疑网络，先把这个低成本动作做了。

2.4 常用排查工具：nslookup、dig、ping的局限

很多人查域名解析第一反应是ping。ping确实会先做DNS解析，然后显示IP，但它只能告诉你“解析有没有成功”，不能精细地告诉你是谁解析的、TTL多少、CNAME是什么。所以正经排查用nslookup和dig。

• nslookup www.example.com：查询指定域名的A记录。
• nslookup -type=CNAME www.example.com：查CNAME。
• dig www.example.com：显示完整解析结果，包括TTL、查询耗时、从哪台服务器得到的答案。
• dig @114.114.114.114 www.example.com：指定某台DNS服务器查询，用来对比不同DNS服务商的解析结果。

举一个真实场景：有人反馈“网站打不开”，我dig一看，返回的IP竟然是以前老服务器的IP；再dig @8.8.8.8一看，新IP没问题。这说明本地DNS服务器的缓存还没过期，于是直接找网络管理员清缓存，问题解决。如果没有这个对比步骤，你很可能在服务器配置里找半天“代码没改”的Bug。

3. TCP/IP与HTTP：传输层和应用层怎么配合

3.1 四层模型速览：抓包时脑子里要有这张表

大学课本喜欢讲OSI七层模型，但实际工程里，抓包、排查、配防火墙时，你用到的几乎都是TCP/IP四层模型。我遇到过一个同事张口闭口“会话层”“表示层”，真到抓包分析时却分不清里边的源IP、目的IP、源端口、目的端口，说明背再多层都没用。

抓过包的朋友一定深有体会：Wireshark里双击一个HTTP包，下面跟着的就是TCP段，再往下是IP包，最底下是以太网帧。每层都有特定的头部信息。排查网络问题，第一件事就是把报错落到某一层：DNS失败？TCP超时？HTTP 502？还是NAT转换异常？判断标准就是看哪一层最先报错。

举个常见例子：Docker拉镜像报dial tcp: lookup registry-1.docker.io: no such host，这是DNS层问题；报connect: network is unreachable，这是网络层问题；报connection reset by peer，这是TCP层问题；报500 Internal Server Error，这是应用层问题。你能定位到层，就已经解决了一半。

3.2 TCP三次握手与四次挥手：为什么连接建立只需要往返一次

TCP是面向连接的、可靠的传输协议。面向连接意味着双方在使用它传数据之前，要先建立一个“会话”。三次握手的过程大家都背过，但这里我想讲的是它背后的两个关键作用：

第一，确认双方的收发能力都正常。客户端发SYN（我能不能说话？），服务器回SYN+ACK（我听得到，你听得到吗？），客户端回ACK（我也听得到）。整个过程只有一次往返加一个确认包，所以叫三次握手。如果网络丢包严重，握手会反复超时，表现就是“连接卡住不动”。

第二，同步初始序列号。TCP是字节流协议，每个包都要编序号，这样接收方才能按序重组。握手时双方会交换初始ISN，后续数据传输都基于这个序号累加。抓包看TCP层时，你能看到Seq和Ack一直在变，那是正常现象。

四次挥手是断开连接的过程。为什么是四次？因为TCP是全双工的，双方可以同时收发数据。A说“我发完了”（FIN），B先回ACK“我知道了”；然后B把自己这边还有的数据发完，再说“我也发完了”（FIN），A再回ACK。所以最简化的挥手也需要四个包。

但实际工程里有个非常常见的问题：大量短连接导致TIME_WAIT状态堆积。主动关闭连接的一方在收到对端ACK后，要等2*MSL（最大报文段生存期）才真正释放端口，目的就是防止迟到的旧连接数据干扰新连接。如果你服务器上跑着高并发的HTTP服务，并且大量主动关闭连接，你netstat一看一堆TIME_WAIT，那多半是没开连接复用导致的，不是系统坏了。

3.3 HTTP协议与Keep-Alive：连接复用是怎么省时间的

HTTP本身是“无状态”的应用层协议。早期HTTP/1.0的每个请求都要新建一次TCP连接，请求完就断开。这样做的代价是：每请求一个资源（HTML、CSS、JS、图片）都要经历三次握手，如果页面需要50个资源，那就是50次握手，时间全耗在网络往返回合上了。

HTTP/1.1引入了Keep-Alive机制，允许一个TCP连接上连续发送多个HTTP请求，直到连接空闲超时或主动关闭。这就是连接复用。它的效果是：首次建立连接的开销被摊分到所有后续请求上，后续每个请求只需要一次往返就能完成。所以你现在看到浏览器Network面板里，大部分资源都复用同一个TCP连接，不会每张图都重新握手。

到了HTTP/2，又进一步提出了多路复用（Multiplexing）：在同一个TCP连接上并发发送多个请求和响应，用帧（frame）和流（stream）来区分不同请求。这时候TCP连接数可以更少，但代价是对TCP的拥塞控制更敏感，因为一个丢包会阻塞多条流。我实测过在丢包率高的链路上，HTTP/2有时反而比HTTP/1.1慢，原因就在这里。

排查HTTP问题时，除了关注状态码，还要看响应Header里的Connection、Keep-Alive、Content-Type。Content-Type决定浏览器怎么解析响应，如果服务器返回application/json，但你取到的却是text/html，多半是后端配置错误或者被网关改写了Header。这也是热搜里经常出现HTTP Content-Type的原因。

3.4 常见HTTP报错定位：500、502、超时的不同含义

网络相关的HTTP报错很多，这里只说最影响开发的几类：

• 500 Internal Server Error：服务器内部出错了，多半是应用代码、数据库连接、运行时异常。排查方向是后端日志。
• 502 Bad Gateway：网关或代理后面那台真实服务器不可用。比如Nginx后面连着Tomcat，Tomcat挂了，Nginx就可能返回502。
• 503 Service Unavailable：服务在线，但暂时无法处理请求，比如被限流或正在启动。
• 504 Gateway Timeout：网关等后端响应超时了。特别容易发生在Docker、代理场景下，下游服务处理太慢，上游等不及就报504。

之前有个朋友排查idea总是报错cannot start internal http server，其实就是IDE自带的本地HTTP服务端口被占用或者防火墙拦截了。这种情况下报错会直接告诉你是端口、网络绑定问题，按HTTP层思路查就好：先看端口有没有被占用（netstat -ano | findstr 8080），再看IDE配置的主机地址是不是localhost被解析成IPv6导致异常。

4. ICMP：网络的“体检报告”，也是故障定位的起点

4.1 ping的真相：ICMP回显请求/应答

ICMP（Internet Control Message Protocol）是网络层的辅助协议。它不承载业务数据，而是用来传递网络控制信息和错误报告。其中最广为人知的用法就是ping，它发送ICMP Echo Request报文，目标主机收到后回复ICMP Echo Reply。如果能收到Reply，说明这条链路的网络层基本通；如果收不到，问题可能出现在本机路由、中间路由器、目标防火墙等多个环节。

关键要搞清楚：ping不通并不代表对方真的不通。很多服务器把ICMP关闭了，你ping不通它，但它的HTTP服务完全正常。所以现在更推荐的探活方式是直接curl目标端口，比如curl -v telnet://192.168.1.10:80，或者用nc -zv。这是经验之谈：只靠ping去判断服务状态，会误报很多故障。

反过来说，ping通也不代表业务可用。我曾经把一个内网服务从192.168.1.10迁移到新机器192.168.1.20，旧机器还在原地，ping新机器通，但端口根本没监听。所以ping只能当网络层的“血压计”，不能当业务体检报告。

4.2 traceroute：利用TTL超时画路径

traceroute（Windows上是tracert）是另一个基于ICMP的经典工具。它的原理很有意思：向目标发送一个TTL=1的报文，经过第一个路由器后TTL减为0，路由器丢弃这个包并回复ICMP Time Exceeded。接着发送TTL=2的包，第二个路由器回复超时……如此反复，你就得到了从本机到目标之间经过的所有跳点。

实际输出里能看到每一跳的IP和延迟。如果某一行显示* * *，说明那一跳没有回应ICMP。常见原因是路由器关闭了TTL超时回包，不一定是线路断了。所以看到中间某跳超时不要慌，继续往后看，只要最终目标能通，链路就是通的。

有一年在客户现场排查“跨地区访问数据库特别慢”的问题，我用了traceroute，发现数据绕了好几个节点，路径比最优路径多出好几跳。和网络运营商一沟通，原来是路由策略的问题。这就是traceroute价值所在：它能还原实际路径，让你看到数据到底在走哪条路。

4.3 Wireshark实测ICMP包结构与重定向

Wireshark里抓ICMP包，你能看到ICMP包的内部结构：Type、Code、Checksum、Identifier、Sequence number。Type=8表示Echo Request，Type=0表示Echo Reply，Type=11表示Time Exceeded，Type=5是ICMP Redirect（路由重定向）。很多人知道抓HTTP包，但很少刻意抓ICMP包——其实ICMP抓包能揭示不少网络层问题。

比如ICMP Redirect：当主机把本应发给网关的报文扔给了另一个路由器，那个路由器发现“你应该直接找隔壁路由”，就回一个ICMP Redirect，告诉主机改变路由。这种机制大多数情况下是好的，但如果网络里有不怀好意的设备，也可能利用重定向做流量劫持。所以很多安全加固手册会要求禁用ICMP Redirect。搜索关键词里有“icmp 改变路由”和“科来icmp抓包”，说明大家确实会碰到这类问题。

实际排查中，ICMP重定向最常见的场景是：本机配置了两个网卡，或者网关配错，导致数据包走了“冤枉路”。你抓包时看到大量ICMP Redirect包，就该检查本机路由表了。用Wireshark过滤icmp就能直接看类型，比看命令行输出直观得多。

5. NAT/NAPT：让一个公网IP扛起整个内网

5.1 NAT到底改了什么：源IP、源端口、映射表

NAT（Network Address Translation）解决的问题很简单：公网IPv4地址不够用，但你家有手机、电脑、电视都要上网，总不能每台设备都配一个公网IP吧。于是路由器把内网设备的所有流量，统一用一个公网IP发送出去。

但这里有个矛盾：如果只是把内网IP换成公网IP，当服务器回复数据的时候，路由器怎么知道这个回包该给哪台内网设备？这就是NAPT（Network Address Port Translation）的用武之地。它会把“内网IP + 内网端口”和“公网IP + 公网端口”映射成一张表：

当服务器返回数据时，路由器根据公网端口反查表项，再把数据送还给对应的内网设备。所以单纯的NAT只改IP，而NAPT同时改IP和端口。家用路由器、公司防火墙、云服务器上的SNAT，基本都是NAPT。

这个机制解释了为什么TCP/UDP连接需要唯一的端口。如果两台内网设备用同一个源端口去访问同一个目的服务器，NAPT还能通过不同公网端口区分它们。换句话说，NAPT让“连接”成为识别不同设备的唯一凭证。

5.2 家里的路由器、公司的防火墙、云服务器的DNAT

NAT/NAPT不只是家用路由器的功能，它在各种环境里都有应用：

• 家用路由器：默认是SNAT（源地址转换），内网设备上网全靠它。
• 公司防火墙：除了SNAT，还用DNAT（目的地址转换）把公网IP的某个端口映射到内网某台服务器上。比如外部访问203.0.113.5:8443，防火墙把它转给内网192.168.1.100:8080。
• 云服务器安全组：这里的“安全组”本质上是防火墙规则，但公网IP到内网IP的映射同样涉及NAT。公有云里实例拿到的可能只是一个私网IP，EIP（弹性公网IP）是通过NAT绑定上去的。

理解DNAT是排查“外网访问不了内网服务”的关键。常见错误是只配了安全组/防火墙开放端口，忘了在网关或路由器上做端口映射。还有一种坑：内网服务器自己开了服务，你在内网用192.168.1.100:8080能访问，但用公网IP访问不行，大概率就是DNAT没配，或者端口映射的内网地址配错了。

5.3 NAT对排查问题的影响：为什么从外网访问不了内网

我总结了几个和NAT相关的常见问题，你可以直接对照：

1. 内网能访问，公网不能访问：首先检查DNAT/端口映射是否存在；其次检查防火墙放行；最后检查服务器监听地址是不是0.0.0.0，如果服务只监听了127.0.0.1，那任何外部流量都进不来。
2. 服务正常，但延迟忽高忽低：看一下是不是多个内网设备在争抢同一个公网IP连接，导致NAPT表项满了。NAPT表容量是有限的，大量连接建立又释放时，可能占满映射表，新连接无法建立。
3. Docker容器网络特别慢：Docker默认的NAT模式会把容器内网地址（通常是172.17.x.x）映射到宿主机的IP和端口。如果宿主机防火墙没放行对应端口，外部根本访问不到容器服务。搜索热词里有“docker search redis request returned 500 internal server error”，这往往不是NAT问题，但排查时也要考虑到：这个请求到底是从容器发起还是宿主机发起，中间是否存在一层端口转发。

还有一个容易被忽略的点：NAT会影响ICMP和traceroute的路径判断。有些家用路由器不给ping回包做NAT转换，你在外网ping内网设备会失败，但业务端口却是通的。

6. 综合排查实战：从Docker报错复现一次完整定位

6.1 案例背景与分包思路

用一个我真实处理过的场景来收尾。某次同事反馈：docker search redis报错，提示：

error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection

这个报错本质是Docker Daemon请求Docker官方仓库时，HTTP请求在等待连接阶段被取消了。按照我们前面讲的链路，我做了这么几步：

1. 先看DNS：nslookup registry-1.docker.io，结果返回正常。
2. 再看TCP：curl -v https://registry-1.docker.io/v2/，发现卡在TCP连接阶段，迟迟没有响应。
3. 接着ping官方仓库IP，发现延迟正常。
4. 最后看路由和MTU，怀疑是中间链路问题。

排查网络问题时，我习惯按“DNS -> TCP -> HTTP -> 应用层”的顺序切分。每一步都能精确判断出是否正常，避免在错误层浪费时间。

6.2 逐层排查的完整过程

先说结论：那次问题出在网络环境的MTU（最大传输单元）上。容器网络默认的MTU是1500，但有些云主机或虚拟化环境的底层链路MTU更低（比如1450或1400）。当Docker Daemon发送的TCP数据包过大，中间路由器又无法分片，就会出现“TCP握手成功了，但数据传不过去”的现象，表现就是HTTP请求卡住直到超时取消。

验证方法很简单：ping -M do -s 1472 registry-1.docker.io，如果提示需要对包分片但又不允许分片，说明中间链路MTU小于1500。

解决办法是把Docker的MTU调低。在/etc/docker/daemon.json里加：

{ "mtu": 1450 }

然后重启Docker：

sudo systemctl restart docker

这里强调一个细节：调整MTU后，已经创建的网络可能不生效，需要重建网络或者把容器重新创建一下。这是我踩过的坑，只改daemon配置不重建网络，问题依旧。

另外，还有一个很常见的坑是DNS配置。如果Daemon所在主机使用公司内部DNS，而这个DNS对registry-1.docker.io返回了错误IP，那curl会连到一个假地址，超时。所以排查顺序一定是先DNS后TCP，不要一上来就怀疑“Docker坏了”。

6.3 避坑总结

我把这些年频繁遇到的几个网络问题整理成一张速查表，方便你抄作业：

网络排查最忌讳的就是凭感觉跳层。我见过太多人一看到超时就去调服务端代码，结果最后问题出在网关。正确做法是拿着抓包工具和命令行工具，沿着协议栈逐层验证。这套方法放到任何环境——笔记本、服务器、嵌入式设备——都适用。

最后再分享一个我个人的小习惯：在/etc/hosts里，我只会放必要的内网映射，绝不放公网域名。因为一旦放了公网域名，测试时你以为在访问线上服务，结果被hosts指到了别处，很容易污染测试结果。另外，每次排查完网络问题，我会顺手写一下“现象 + 根因 + 验证命令”到自己的笔记里。这种习惯帮我积累了不少排查模板，下次碰到相似问题，十分钟就能定位。