Blog

Zachary

IP 地址、网络掩码、网段、网关、路由和 DNS 的关系

发布于 # 网络

这一组概念属于“网络访问路径”的基础。可以先把一次网站访问拆成两条链路来记。

第一条是寻址和转发路径：

域名
=> DNS 查到 IP
=> 本机用 IP + 掩码判断目标是否同网段
=> 路由表决定本地直连还是交给网关
=> 如果要交给网关，先用 ARP 找到网关的 MAC 地址
=> 交换机按 MAC 地址转发到网关或下一台设备
=> 路由器按路由表继续转发
=> 出口设备可能做 NAT
=> 数据到达目标网络

第二条是应用访问路径：

目标 IP 可达
=> TCP 或 UDP 建立对应通信
=> 端口把连接交给目标主机上的具体服务
=> 如果是 HTTPS，TLS 用证书确认身份并加密
=> HTTP/HTTPS 传输真正的网页、API、文件或消息

再压缩成一句话：DNS 负责把名字查成 IP；IP 地址标识网络层通信目标或接口地址；掩码和网段决定能否本地直连；路由决定下一跳；网关是某些路由的下一站；ARP 和 MAC 负责本地链路上的下一跳交付；NAT 可能在出口改写地址和端口；协议规定双方怎么说话；端口区分同一台机器上的不同服务；证书和 TLS 负责 HTTPS 场景下的身份验证和加密。

物理连接和 Wi-Fi 只是前提

电脑要访问网络，第一步不是 DNS，也不是 IP，而是先要接入某种网络介质。

常见接入方式包括：

有线网卡 + 网线 + 交换机/路由器端口
无线网卡 + Wi-Fi + 无线 AP/家用路由器
虚拟网卡 + VPN/Docker/虚拟机网络

如果网线没有插好、Wi-Fi 没连上、网卡被禁用，后面的 IP、DNS、网关、路由都谈不上。Windows 右下角网络图标出现红叉，或者设置里显示“网络电缆被拔出”“未连接”，通常就是这一层的问题。

但反过来，网络图标显示已连接，也不等于一定能访问互联网。它只说明电脑已经接入了某个本地网络。接下来还要看有没有正确的 IP、掩码、网关、DNS、路由、防火墙和出口 NAT。

IP 地址

IP 地址是网络层通信里的地址，作用类似“收件地址”。当你的电脑访问一个网站时，浏览器最终不是直接向 example.com 这个文本发数据，而是先得到一个 IP 地址，再把数据包发向那个 IP。

更准确地说，IP 地址通常标识的是网络层通信目标或某个网络接口地址，而不是永远一对一标识“一台真实机器”。原因是：

IPv4 地址常写成四段数字，例如：

192.168.1.23
8.8.8.8
203.0.113.10

IPv6 地址更长，常写成十六进制分组，例如：

2400:3200::1
2001:4860:4860::8888

但 IP 地址本身只说明“目标地址是什么”，不单独说明“目标和我是不是在同一个局域网”“该从哪个出口发出去”。这些问题要靠网络掩码、网段、网关和路由一起判断。

常见误区：

为什么 192.168.x.x 通常是内网地址：因为互联网标准专门保留了几段 IPv4 地址给私有网络使用，其中就包括 192.168.0.0/16。这些地址不会在公网互联网的全局路由表里被正常转发。家用路由器、公司内网、虚拟机、Docker 等可以在自己的内部网络里重复使用这些地址，不需要向运营商或注册机构申请唯一公网 IP。

这也是为什么很多家庭路由器默认地址是 192.168.1.1 或 192.168.0.1：路由器在家里创建了一个私有局域网，给手机、电脑、电视分配 192.168.x.x 这类地址；然后路由器自己再通过运营商给的公网地址或上级网络地址访问互联网。内网设备出网时，常见做法是通过 NAT 把多个内网地址共享成一个公网出口。

这和 DNS 的关系是：DNS 解析只负责给出某个名字对应的目标地址，但它不知道你心里想访问的是“哪台真实设备”。如果 DNS 返回的是公网 IP，公网用户通常能按互联网路由去找；如果 DNS 返回的是内网 IP，只有和这个内网 IP 处在同一私有网络，或通过 VPN/隧道进入该网络的用户，才可能访问到正确目标。

DHCP

很多电脑不是手动配置 IP，而是通过 DHCP 自动获得网络配置。

DHCP 常见会分配这些信息：

IP 地址
子网掩码
默认网关
DNS 服务器
租约时间

家庭网络里，DHCP 服务器通常就是家用路由器。公司网络里，可能是专门的 DHCP 服务器、防火墙、三层交换机或网关设备。云服务器、容器、虚拟机也常通过类似机制获得地址。

如果 DHCP 正常，Windows 里执行：

ipconfig /all

通常能看到当前网卡的 IPv4 地址、子网掩码、默认网关和 DNS 服务器。

如果 DHCP 失败，常见信号是：

IPv4 地址为空
没有默认网关
IPv4 地址以 169.254. 开头

169.254.0.0/16 是链路本地地址范围。它通常表示电脑没有从 DHCP 成功拿到正常地址，只能在本地链路上做非常有限的通信。此时你可能看到网卡“已连接”，但仍然无法正常访问互联网。

网络掩码

网络掩码用来告诉设备：一个 IP 地址里，前面哪一部分表示“网络”，后面哪一部分表示“主机”。换句话说，网络掩码决定“哪些 IP 算同一个网段”。

最常见的写法有两种。

第一种是点分十进制掩码：

255.255.255.0
255.255.0.0
255.255.255.128

第二种是 CIDR 前缀长度：

/24
/16
/25

它们可以互相对应：

255.255.255.0   = /24
255.255.0.0     = /16
255.255.255.128 = /25

以 192.168.1.23/24 为例：

为什么需要掩码：单看 192.168.1.23，你不知道它认为谁是“邻居”。配上 /24 后，它才知道 192.168.1.50 是同网段，192.168.2.50 不是同网段。

掩码配错的影响很直接：

网段

网段就是由“网络地址 + 掩码”定义出来的一组 IP 地址。例如：

192.168.1.0/24
10.0.0.0/8
172.16.0.0/12

以 192.168.1.0/24 为例：

同一个网段内的设备通常可以直接二层通信。例如你的电脑是 192.168.1.23/24，打印机是 192.168.1.50/24，它们都在 192.168.1.0/24，电脑一般可以直接找打印机。

不同网段通常不能直接通信。例如：

电脑：192.168.1.23/24
目标：192.168.2.50/24

电脑会判断 192.168.2.50 不在自己的 192.168.1.0/24 网段，于是不会直接发给目标，而是把数据交给网关。

局域网和网段的区别

局域网和网段不是一回事，也不是“一个代表内网、一个代表公网”。

局域网强调的是一个相对局部的网络环境，通常由同一个家庭、办公室、机房机柜、实验室、虚拟网络或公司内部网络管理。它是一个偏“物理或管理范围”的概念：哪些设备在同一个本地网络里，由同一套路由器、交换机、无线 AP、防火墙或云 VPC 管。

网段强调的是一组 IP 地址范围，是一个偏“地址和路由”的概念。例如：

192.168.1.0/24
10.0.0.0/16
203.0.113.0/24

所以更准确的关系是：

家庭网络里最常见的情况是“一个局域网约等于一个内网网段”：

家庭局域网：由家里的路由器和 Wi-Fi 管理
常见网段：192.168.1.0/24
路由器/网关：192.168.1.1
手机：192.168.1.20
电脑：192.168.1.23
电视：192.168.1.50

因为家庭网络通常很简单，所以很多人会把“局域网”“内网”“192.168.1.0/24 网段”混着说。但在公司或云网络里，这种说法就不够准确了。

例如一个公司局域网可能包含多个内网网段：

办公电脑网段：10.10.1.0/24
打印机网段：10.10.2.0/24
服务器网段：10.10.10.0/24
访客 Wi-Fi 网段：10.10.99.0/24

它们都属于公司内网，但不是同一个网段。办公电脑要访问服务器，通常要经过三层交换机、路由器或防火墙转发。

公网同样有网段。例如云服务器拿到的一个公网 IP，它可能属于云厂商分配的一段公网地址。公网网段会被互联网路由系统传播，私有网段则不会在公网中正常路由。

因此可以这样记：

局域网：一组本地设备组成的网络环境。
网段：一组按 IP 地址和掩码划出来的地址范围。
内网：不直接暴露在公网的私有网络环境。
公网：可在互联网中全局路由访问的网络地址空间。

一句话总结：内网有网段，公网也有网段；局域网通常使用内网网段，但“局域网”不是“网段”的同义词。

网关

网关通常指默认网关，也就是“离开当前网段时，数据包先交给谁”。在家庭网络里，默认网关通常就是路由器的内网地址，例如：

电脑 IP：192.168.1.23
掩码：255.255.255.0
默认网关：192.168.1.1

当电脑访问 192.168.1.50 时：

192.168.1.23/24 和 192.168.1.50/24 同网段
=> 直接在局域网里找 192.168.1.50

当电脑访问 8.8.8.8 时：

8.8.8.8 不在 192.168.1.0/24
=> 交给默认网关 192.168.1.1
=> 由路由器继续转发到互联网

这里有一个关键点：在常见以太网主机的默认网关配置里，网关本身通常必须在你的本地网段内。因为你的电脑要先能直接找到网关，才能把出网流量交给它。比如电脑是 192.168.1.23/24，默认网关一般可以是 192.168.1.1，但不应该写成 192.168.2.1，否则电脑连网关都直连不到。

这个说法针对的是最常见的主机以太网场景。更特殊的点到点链路、静态路由、Proxy ARP、隧道或运营商网络配置可能有例外，但初学排障时先按“默认网关要能被本机直连”理解最稳。

路由和网关的关系

路由和网关的关系可以这样理解：路由是规则，网关是某些路由规则指定的下一跳设备。

你的电脑不是看到一个目标 IP 就直接乱发，它会先查自己的路由表。路由表里每条规则大概都在回答这个问题：

如果目标 IP 属于这个范围，下一步应该怎么走？

其中有些规则的答案是“直接从本机网卡发出去”，有些规则的答案是“交给某个网关”。这个“某个网关”就是下一跳。

以家庭网络为例：

电脑 IP：192.168.1.23/24
默认网关：192.168.1.1

电脑的路由表可以简化理解为：

去 192.168.1.0/24     => 直接从本地网卡发，不经过网关
去 0.0.0.0/0          => 交给网关 192.168.1.1

当访问 192.168.1.50：

目标 192.168.1.50 匹配 192.168.1.0/24
=> 这是本地网段
=> 电脑直接在局域网里找 192.168.1.50
=> 不需要交给默认网关

当访问 8.8.8.8：

目标 8.8.8.8 不匹配 192.168.1.0/24
=> 匹配默认路由 0.0.0.0/0
=> 交给默认网关 192.168.1.1
=> 由路由器继续转发

所以“网关”不是一个神秘概念，它本质上是本机能直接到达的一台路由设备。你的电脑把自己不知道怎么直接到达的目标，先交给这台设备处理。

默认网关是最常见的网关。它对应默认路由：

0.0.0.0/0 via 192.168.1.1

0.0.0.0/0 表示“所有 IPv4 地址”。但这并不是说所有流量都无条件交给默认网关，因为路由选择遵循更具体规则优先。比如本地网段 192.168.1.0/24 比 0.0.0.0/0 更具体，所以访问同网段设备会优先走本地直连。

在简单家庭网络里，通常只有一个默认网关，也就是家用路由器。它同时扮演几个角色：

但在复杂网络里，路由和网关不会总是这么简单。一个设备可以有多条路由，指向多个不同网关。例如公司网络或 VPN 场景：

去 10.10.0.0/16       => 交给公司 VPN 网关 10.8.0.1
去 192.168.1.0/24     => 本地直连
去 0.0.0.0/0          => 交给家里路由器 192.168.1.1

这种情况下：

这就是为什么有时“开了 VPN 后某些网站打不开”“Docker 容器和公司内网网段冲突”“能访问互联网但访问不了公司服务器”：问题往往不是 DNS，而是路由表里某条规则把流量交给了错误的网关，或者两个网段重叠导致系统不知道该走哪边。

可以用一句话总结：

路由决定“目标该怎么走”；网关是“某条路由选择的下一跳”。

路由

路由是“到某个目标网络，下一步该往哪里发”的规则。设备里通常有一张路由表。路由表可以很复杂，但初学先理解三类就够：

本地网段路由：去 192.168.1.0/24，直接从本地网卡发
默认路由：其他不知道去哪的目标，交给默认网关 192.168.1.1
特殊路由：去某个特定网段，交给某个特定下一跳

默认路由通常写成：

0.0.0.0/0 via 192.168.1.1

在 Windows 里执行：

route print

可以查看本机路由表。IPv4 路由表里如果看到：

网络目标        网络掩码          网关
0.0.0.0         0.0.0.0           192.168.1.1

就可以理解为：所有没有更精确规则匹配的 IPv4 目标，都交给 192.168.1.1 这个默认网关。

路由匹配遵循“最长前缀优先”。也就是越具体的规则优先级越高。例如同时存在：

10.0.0.0/8 via 192.168.1.1
10.1.2.0/24 via 192.168.1.254
0.0.0.0/0 via 192.168.1.1

访问 10.1.2.33 时，会优先匹配 10.1.2.0/24，因为它比 10.0.0.0/8 更具体。

路由不只存在于家用路由器里。你的电脑、手机、云服务器、Docker 容器、公司 VPN、云厂商 VPC 都有路由概念。很多“能解析域名但打不开网站”的问题，实际上不是 DNS 错，而是路由、防火墙、NAT、端口或服务器问题。

ARP、MAC 地址和交换机

IP 和路由解决的是“目标网络层地址怎么走”，但本地链路上真正把数据帧交给下一台设备时，还需要 MAC 地址。

MAC 地址是以太网等二层网络中使用的地址。交换机主要根据 MAC 地址表转发以太网帧，而不是根据域名或公网 IP 转发。

以电脑访问公网网站为例：

电脑 IP：192.168.1.23
默认网关：192.168.1.1
网站 IP：203.0.113.10（示例地址）

电脑发现网站 IP 不在本地网段，于是三层目标仍然是网站 IP，但下一跳是默认网关。为了把数据交给默认网关，电脑需要知道 192.168.1.1 对应的 MAC 地址。

这一步通常通过 ARP 完成：

电脑广播：谁是 192.168.1.1？请告诉 192.168.1.23。
网关回应：192.168.1.1 的 MAC 是 xx-xx-xx-xx-xx-xx。
电脑缓存：192.168.1.1 -> xx-xx-xx-xx-xx-xx。

Windows 里可以执行：

arp -a

查看当前 ARP 缓存。如果你刚执行过：

ping 192.168.1.1

通常会在 arp -a 中看到默认网关 IP 对应的 MAC 地址。

这里很容易混淆一件事：访问外网时，IP 包的目的 IP 是网站服务器；以太网帧的目的 MAC 通常是默认网关。也就是说：

三层目的 IP：网站服务器 IP
二层目的 MAC：默认网关 MAC

交换机收到这个帧后，按 MAC 地址表把它转发到连接默认网关的端口。网关收到后，再解开二层帧，看里面的 IP 包，然后按路由表继续转发。

补充限制：ARP 是 IPv4 常见机制。IPv6 不使用 ARP，而使用邻居发现协议 NDP。所以如果你的网络主要走 IPv6，arp -a 不能完整解释 IPv6 的邻居发现过程。

DNS

DNS 负责把人类容易记的名字转换成网络需要的记录。最常见的是把域名查成 IP：

example.com -> A 记录 -> IPv4 地址
example.com -> AAAA 记录 -> IPv6 地址

DNS 和网关、路由的关系是先后关系，不是替代关系：

你输入 https://example.com
=> DNS 查询 example.com 的 IP
=> 得到 IP
=> 系统查看路由表，判断这个 IP 怎么走
=> 发现不在本地网段，交给默认网关
=> 网关继续转发到互联网

所以：

如果 DNS 配错，常见表现是域名查不到 IP，或者查到错误 IP。

如果网关配错，常见表现是能访问同局域网设备，但不能访问互联网。

如果掩码配错，常见表现是设备误判哪些地址属于本地网段，导致本来该交给网关的流量被当成本地直连，或者本来能直连的设备被错误交给网关。

如果路由配错，常见表现是某些网段能访问，某些网段不能访问，尤其常见于 VPN、Docker、虚拟机、云服务器和多网卡环境。

DNS 返回的 IP 也不是永远固定的。大型网站常有多地址、CDN、运营商调度和 IPv4/IPv6 差异，同一域名不同时间、地区、DNS 服务器返回结果可能不同。因此不要把某次 nslookup 查到的 IP 当成长期固定答案。

协议

协议就是通信规则。两台设备能互相发包还不够，双方还必须约定“数据怎么组织、怎么开始、怎么结束、出错怎么办、字段是什么意思”。这些约定就是协议。

可以按层次理解几个常见协议：

IP：负责把数据包从一个 IP 地址送向另一个 IP 地址。
TCP：在 IP 之上提供可靠连接，常用于 HTTP/HTTPS、SSH、数据库等。
UDP：在 IP 之上提供较轻量的数据报传输，常用于 DNS、QUIC、实时音视频等。
DNS：把域名查成 IP 或其他记录。
HTTP：浏览器和网站服务器之间传输网页、API 响应等内容的应用协议。
TLS：给上层应用提供加密和身份验证，HTTPS 就是 HTTP over TLS。
HTTPS：不是一个完全独立于 HTTP 的新东西，可以理解为 HTTP + TLS。
SSH：远程登录服务器的协议，常用 TCP 22 端口。

协议和端口不是一回事。协议规定“怎么说话”，端口负责“找哪个服务”。通常大家会说 HTTPS 使用 443 端口，这只是默认约定；理论上 HTTPS 服务也可以开在 8443，HTTP 服务也可以开在 8080。但如果使用非默认端口，访问时通常要明确写出来，例如：

https://example.com:8443
http://example.com:8080

常见误区是把“端口号”当成“协议本身”。例如 443 端口通常跑 HTTPS，但端口号本身不会自动保证里面一定是 HTTPS；真正决定双方能不能通信的，是客户端和服务端是否在这个端口上使用同一种协议。

端口

端口是同一台机器上区分不同网络服务的编号。IP/路由负责把包送到目标网络层地址，TCP/UDP 端口负责把连接或数据报交给目标主机上的具体服务进程。

可以这样理解：

IP 地址：把快递送到哪栋楼
端口：送到这栋楼里的哪个房间
协议：房间里的人按什么语言和规则交流

一个服务器可以同时运行多个服务：

22/tcp   => SSH 远程登录
80/tcp   => HTTP 网站
443/tcp  => HTTPS 网站
3306/tcp => MySQL
5432/tcp => PostgreSQL
6379/tcp => Redis

所以 203.0.113.10:443 和 203.0.113.10:22 是同一个示例 IP 上的两个不同入口。浏览器访问 https://example.com 时，如果 URL 里没有写端口，浏览器会按协议选择默认端口：

http://example.com  => 默认 TCP 80
https://example.com => 默认 TCP 443

端口号范围是 0 到 65535。常见分类可以粗略记成：

0-1023：系统端口 / well-known ports，常见服务默认端口多在这里
1024-49151：用户端口 / registered ports
49152-65535：动态或私有端口 / ephemeral ports

客户端访问网站时，服务端通常监听固定端口，例如 443；客户端自己也会临时分配一个本地随机高位端口。例如：

你的电脑：192.168.1.23:52344
访问目标：203.0.113.10:443（示例地址）

这里的 52344 是客户端临时端口，用来区分本机同时发起的多个连接；443 是服务端 HTTPS 服务端口。

防火墙、NAT 和端口转发

端口还会和防火墙、NAT、端口转发纠缠在一起。

防火墙负责允许或拒绝某些流量。例如服务器安全组只开放 22 和 443，那么即使 DNS 解析正确、路由也通，访问 3306 端口仍然会失败。

NAT 常见于家庭路由器。家里多台设备使用 192.168.x.x 内网地址出网时，路由器会把它们的连接转换成公网出口地址和不同端口。这样多个内网设备能共享一个公网出口。

一个典型的出网 NAT 可以这样理解：

内网电脑：192.168.1.23:52344
访问目标：203.0.113.10:443（示例地址）
出口改写后：公网出口IP:某个端口 -> 203.0.113.10:443

目标服务器回包时，并不知道你家里的 192.168.1.23。它只会回给看到的公网出口地址和端口。出口路由器或防火墙再根据 NAT 会话表，把回包还原并转发给内网电脑：

公网出口IP:某个端口
=> 查 NAT 会话表
=> 还原到 192.168.1.23:52344
=> 送回内网电脑

这解释了为什么 NAT 不是简单的“把地址换一下”：它还要记录会话，才能知道返回流量应该交给哪台内网设备。

端口转发是 NAT 的反向用法之一：把公网入口的某个端口转发到内网某台机器的某个端口。例如：

公网 IP:8443  =>  192.168.1.100:443

这表示外部访问你家公网 IP 的 8443 端口时，路由器把流量转给内网机器 192.168.1.100 的 443 端口。

这也解释了为什么“把家里电脑的 192.168.1.100 写进公网 DNS”没用：公网用户无法直接路由到这个内网地址。你需要的是公网入口、端口转发或隧道方案，而不是只改 DNS。

NAT 在私网访问公网时很常见，但不是所有网络路径都必须 NAT。拥有公网 IPv4 地址、IPv6 全局地址、专线、隧道或代理出口时，路径可能不同。

证书、TLS 和 HTTPS

证书通常指 SSL/TLS 证书。现在更准确的说法是 TLS 证书，只是很多产品页面仍然沿用 SSL 这个历史名称。

在 HTTPS 访问中，证书主要解决两个问题：

身份验证：证明你访问的服务器有权代表这个域名。
加密协商：帮助浏览器和服务器建立加密连接，防止通信内容被旁路读取或篡改。

当浏览器访问：

https://blog.example.com

大致过程是：

  1. DNS 先把 blog.example.com 查成 IP。
  2. 路由和网关把连接送到目标 IP 的 443 端口。
  3. 浏览器和服务器进行 TLS 握手。
  4. 服务器出示证书。
  5. 浏览器检查证书是否由可信 CA 签发、是否在有效期内、证书里的域名是否覆盖 blog.example.com、证书链是否完整。
  6. 检查通过后，双方协商出加密密钥。
  7. 后续 HTTP 内容在 TLS 加密通道里传输，也就是 HTTPS。

证书不是 DNS 记录，也不是端口。它依赖域名，但作用在 HTTPS 连接阶段。DNS 正确只能让浏览器找到目标 IP；证书正确才能让浏览器信任这个 HTTPS 连接。

几个常见错误：

以 Cloudflare 为例，用户浏览器到 Cloudflare 边缘节点是一段 TLS；Cloudflare 到你的源站服务器又是另一段连接。Full、Full (strict) 等模式影响的是 Cloudflare 到源站这段如何验证证书。尤其是 Full (strict) 要求源站证书有效，否则可能出现 526 这类证书错误。

一个完整访问例子

假设你的电脑网络配置如下：

IP 地址：192.168.1.23
网络掩码：255.255.255.0，也就是 /24
网段：192.168.1.0/24
默认网关：192.168.1.1
DNS 服务器：1.1.1.1
网关 MAC：aa-bb-cc-dd-ee-ff（示例）

你在浏览器输入：

https://blog.example.com

整个过程可以拆成：

  1. 浏览器把 blog.example.com 交给系统解析。
  2. 系统向 DNS 服务器 1.1.1.1 查询 blog.example.com。
  3. DNS 返回一个 IP，例如文档示例地址 203.0.113.10。
  4. 电脑用自己的 IP 和掩码判断：203.0.113.10 不在 192.168.1.0/24。
  5. 电脑查路由表，发现默认路由指向 192.168.1.1。
  6. 电脑用 ARP 查询或读取缓存，得到默认网关 192.168.1.1 的 MAC 地址。
  7. 电脑封装数据：三层目的 IP 是 203.0.113.10，二层目的 MAC 是默认网关 MAC。
  8. 交换机按 MAC 表把帧送到默认网关所在端口。
  9. 路由器收到帧后取出 IP 包，查路由表，把流量转发到运营商网络或上级路由器。
  10. 家庭或企业出口设备可能执行 NAT，把内网源地址和端口改写成公网出口地址和端口。
  11. 数据经过互联网到达目标服务器或目标服务前面的 CDN/负载均衡。
  12. 因为 URL 是 https://，浏览器默认连接目标的 TCP 443 端口。
  13. 服务器在 443 端口上提供 HTTPS 服务，双方进行 TLS 握手。
  14. 服务器出示证书，浏览器检查证书是否可信、是否覆盖 blog.example.com、是否过期。
  15. TLS 握手成功后，浏览器通过加密通道发送 HTTP 请求。
  16. 目标服务器返回 HTTP 响应。
  17. 回包回到 NAT 出口设备时，出口设备根据 NAT 会话表还原到 192.168.1.23:客户端临时端口。
  18. 内网交换机根据 MAC 表把帧送回电脑网卡。
  19. 浏览器收到响应并显示网页。

如果访问失败，可以按这个顺序排查：

1. 物理网线或 Wi-Fi 是否已连接？
2. 本机有没有正常 IP、掩码、默认网关和 DNS？
3. DNS 有没有解析到目标 IP？
4. 本机路由表决定目标走哪条路？
5. 默认网关是否可达，ARP 是否能解析到网关 MAC？
6. 网关或出口是否能访问互联网？
7. NAT、防火墙、安全组、代理是否允许该流量？
8. 目标服务器端口是否开放，服务是否运行正确协议？
9. HTTPS 证书是否有效、域名是否匹配、证书链是否完整？

Windows 最小排障命令表

想确认什么命令重点看什么
本机是否拿到网络配置ipconfig /allIPv4 地址、子网掩码、默认网关、DNS 服务器、物理地址
域名能否解析nslookup example.com使用的 DNS 服务器、返回的 A/AAAA 记录
默认网关是否可达ping <默认网关IP>是否有回复、延迟是否异常
默认网关的 MAC 是否已解析arp -a默认网关 IP 对应的 MAC 地址
本机路由表如何决定下一跳route print0.0.0.0/0 默认路由、VPN/Docker/虚拟网卡路由
到目标经过哪些三层跳点tracert -d <域名或IP>第 1 跳是否通常为网关，后续是否中断或绕路

tracert 里的 * 不一定表示网络断了。有些路由器不会返回 TTL 超时消息，或者会限制 ICMP 响应，因此 tracert 只能辅助判断路径，不能单独作为最终结论。

和域名托管到 Cloudflare 的关系

购买域名并托管到 Cloudflare，主要解决的是 DNS 层问题：让 Cloudflare 成为这个域名的权威 DNS，然后在 Cloudflare 里配置 A、AAAA、CNAME、MX、TXT 等记录。

但 Cloudflare DNS 记录最终仍然会指向某个 IP 或另一个域名。后面的网络连接仍然要经过掩码、网段、网关和路由判断。

例如你在 Cloudflare 添加：

类型：A
名称：blog
内容：203.0.113.10（文档示例地址）

这表示：

blog.example.com 解析到 203.0.113.10

访问者电脑拿到 203.0.113.10 后，仍要通过自己的路由表和默认网关把流量发出去。DNS 只负责告诉访问者“目标地址是多少”，不负责保证网络路径、服务器服务、端口开放和 HTTPS 配置一定正常。

如果这条记录在 Cloudflare 中是 DNS only，访问者会直接连接源站 IP。如果这条记录开启了 Proxied，访问者通常先连接 Cloudflare 边缘节点，Cloudflare 再按配置回源到源站。这时 DNS、路由、端口、HTTP/HTTPS、TLS 证书仍然都存在，只是连接被拆成了“访问者到 Cloudflare”和“Cloudflare 到源站”两段。

最小记忆表

概念解决的问题例子常见错误
物理/Wi-Fi 连接是否接入了本地网络网线、Wi-Fi、虚拟网卡以为图标已连接就一定能上网
DHCP自动获得网络配置IP、掩码、网关、DNS忽略 169.254.x.x 这类异常地址
IP 地址网络层目标或接口地址192.168.1.23、8.8.8.8把内网 IP 当公网 IP 用
网络掩码哪部分是网络，哪部分是主机255.255.255.0、/24掩码配错导致误判同网段
网段哪些 IP 属于同一个网络192.168.1.0/24以为 IP 前三段相同就永远同网段
网关出本网段先交给谁192.168.1.1网关不在常规本地网段
路由去某个网络下一跳是谁0.0.0.0/0 via 192.168.1.1VPN、多网卡、Docker 路由冲突
ARP/MAC本地链路上下一跳是谁192.168.1.1 -> aa-bb-...以为交换机按公网 IP 转发
DNS名字对应哪个 IP 或记录example.com -> A/AAAA以为 DNS 能解决服务器、防火墙或路由问题
协议双方按什么规则通信HTTP、TLS、SSH、DNS以为端口号等于协议
端口同一台机器上的哪个服务443、22、3306DNS 正确但服务端口没开放
防火墙/NAT哪些流量允许通过，内外地址如何转换安全组、端口转发、NAT 会话表只改 DNS，不开放端口或不做转发
证书/TLSHTTPS 身份验证和加密blog.example.com 的证书DNS 正确但证书过期或域名不匹配