从 ipconfig 出发，彻底搞懂 Windows 网络栈、网卡、路由、DNS 和 Tailscale

Posted on In , Views: Word count in article: 6.3k Reading time ≈ 11 mins.

一台电脑为什么会有多个网卡？为什么 Wi-Fi 能上网，但以太网不行？VPN 又是怎么“插进”系统网络里的？

📚 基本概念速读

名称 定义 省流
网卡（NIC） 电脑连接网络的接口 负责把数据发出去、收回来
IP 地址 主机在网络中的地址 “我是谁”
路由表 决定数据包走哪条路的规则集合 “我怎么去”
默认网关 离开当前局域网时的下一跳 “出小区的门”
DHCP 自动分配网络参数的协议 自动分配 IP、网关、DNS
DNS 把域名翻译成 IP 的系统 google.com 先变成 IP 才能访问
Tailscale 基于 WireGuard 的组网工具 给系统加了一张虚拟网卡和一套路由

最近我把工作机从自己的笔记本换到实验室主机，过程中碰到了一些网络问题。我顺着以太网故障，把 Windows 网络栈、多网卡、路由、DNS 和 Tailscale 重新梳理了一遍。

🌍 从一个真实问题开始

我机器上的网络状态大致是这样的：

1
2
3
4
Wi-Fi:       192.168.5.40   ✅ 正常上网
Ethernet:    169.254.x.x    ❌ 不能上网
Tailscale:   100.72.x.x     ✅ VPN 网络
WSL:         172.27.x.x     🧪 虚拟环境

当时我主要在看两个问题：

以太网不能上网？ 电脑有多个网卡，系统怎么决定流量该走哪一条？

🧠 网络最小模型

排障时抓三个问题：

1
2
3
1. 我是谁       → 本机 IP 地址
2. 我要去哪     → 目标 IP 或域名
3. 我怎么去     → 路由表决定出口

很多网络问题，最后都能收敛到这三件事上。

🧱 Windows 网络栈到底在做什么

在 Windows 里，一个请求从应用发出去，大致会经过下面这条链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌──────────────┐
│   应用程序    │  浏览器 / curl / App
└──────┬───────┘
       │ Winsock
┌──────▼───────┐
│   TCP / UDP  │
└──────┬───────┘
       │
┌──────▼───────┐
│      IP      │
└──────┬───────┘
       │
┌──────▼───────┐
│ NDIS/网卡驱动 │
└──────┬───────┘
       │
┌──────▼───────┐
│     网卡      │
└──────────────┘

这里的 NDIS 可以先理解成 Windows 网络栈和网卡驱动之间的标准接口层。

🔌 网卡是什么，为什么会有这么多

网卡 IP 类型 作用
Wi-Fi 192.168.5.40 物理网卡 正常连接家庭或办公网络
Ethernet 169.254.x.x 物理网卡 当前异常，没正常拿到配置
Tailscale 100.72.x.x 虚拟网卡 VPN / Overlay 网络
WSL 172.27.x.x 虚拟网卡 Windows 宿主机与 Linux 子系统之间的虚拟网络接口

这里有一点需要先明确：

在操作系统眼里，这些网卡是平等的。

系统不会因为名字叫 Wi-Fi 就天然优先使用它。真正决定流量出口的是路由表。

不过，“平等”只表示它们都会作为一个网络接口出现在系统里，不表示它们承担的是同一种工作。可以先把它们分成两类：

1
2
物理网卡：真的连着硬件，负责把数据送到现实世界的网络里
虚拟网卡：由系统、虚拟化或 VPN 软件创建，负责接管或转发特定流量

Wi-Fi：最常见的物理网卡

Wi-Fi 对应的是无线网卡，直接连接家里或办公室的无线路由器。它的特点是：

  • 它真的连着一块硬件，出口是现实里的无线局域网。
  • 它通常会从路由器的 DHCP 拿到 IP、默认网关和 DNS。
  • 如果路由表里的默认路由指向它，大多数普通互联网流量都会从这里出去。

你现在看到的 192.168.5.40 就是一个很典型的家庭或办公网私网地址，说明这张卡已经正常接入了局域网。

Ethernet：也是物理网卡，只是这次状态异常

Ethernet 对应有线网卡，和 Wi-Fi 一样，也是系统眼里的“真实出口”。区别只在于它走的是网线，不走无线电。

正常情况下，它也应该像 Wi-Fi 一样拿到一套完整配置，比如：

1
2
3
4
IP 地址
子网掩码
默认网关
DNS 服务器

但你这里拿到的是 169.254.x.x，这不是正常的局域网分配地址，而是 DHCP 失败后系统自己兜底生成的 APIPA 地址。它说明的是：

  • 网卡硬件未必坏了，链路可能已经插上。
  • 但它没有成功从上游网络拿到正式配置。
  • 没有默认网关和 DNS 时，它通常就不能作为正常的互联网出口。

所以 Ethernet 和 Wi-Fi 的本质区别不是“一个高级一个低级”，而是这次一个配置成功，一个配置失败。

Tailscale：VPN 软件插进系统的一张虚拟网卡

Tailscale 不对应你机器里额外插了一块实体网卡，而是 Tailscale 安装后在系统里创建出来的一张虚拟网卡。它的作用不是直接连家里路由器，而是承接 Tailscale 网络里的流量。

它和物理网卡最大的区别在于：

  • 物理网卡负责把包送到真实二层网络，比如 Wi-Fi 或交换机。
  • Tailscale 虚拟网卡负责把“该进 VPN 的包”先接住。
  • 后续这些包会被 Tailscale 进程加密、封装，再借助底下真正能联网的物理网卡发出去。

所以从系统视角看，100.72.x.x 是一张“可用接口”；但从实现视角看，它自己并不是最终出公网的那条物理链路，而是一个 Overlay 网络入口。

WSL：宿主机和 Linux 子系统之间的虚拟网络接口

WSL 这类 172.27.x.x 地址，通常来自 Windows 为 Linux 子系统准备的虚拟网络。你可以把它理解成宿主机和 WSL 环境之间的连接点。

这类接口的特点是：

  • 它首先服务于 Windows 宿主机和 WSL 之间通信，不是直接面向你家路由器。
  • 它往往由 Windows 的虚拟交换、NAT 或 Hyper-V 风格机制管理。
  • 你在 WSL 里访问外网时，流量通常还会再经过 Windows 宿主机转发，而不是直接从这张虚拟卡“裸奔”出去。

所以 WSL 网卡更像是“宿主机和子系统之间的桥梁 + 出网前的中转接口”，而不是一张独立的外部联网设备。

🚦 路由表才是真正的导航系统

1
route print

通常能看到类似这样的条目：

1
2
3
Network Destination        Gateway        Interface
0.0.0.0/0                192.168.5.1     Wi-Fi
100.x.x.x                On-link         Tailscale

路由表的决策逻辑可以压成两条：

1
2
1. 最长前缀匹配
2. metric 更小者优先

最长前缀匹配是什么意思

假设我访问：

1
google.com → 142.x.x.x

路由表里没有针对 142.x.x.x 的更具体路由，于是系统会落到默认路由：

1
0.0.0.0/0 → Wi-Fi

所以这类普通互联网流量会走 Wi-Fi。

但如果我访问的是 Tailscale 网络里的设备，比如：

1
100.99.x.x

系统会发现有更具体的路由：

1
100.x.x.x → Tailscale

于是它会优先走 Tailscale 虚拟网卡，而不是继续走默认的 Wi-Fi 出口。

🚪 默认网关到底是什么

在 ipconfig 里经常会看到：

1
Default Gateway: 192.168.5.1

我对网关的理解是：

当目标地址不在本地局域网里时，帮我把流量转发出去的下一跳。

比如我自己的 IP 是：

1
192.168.5.40

我要访问 Google：

1
142.x.x.x

这两个地址显然不在同一个局域网里。我不可能直接把数据包发给 Google，所以只能先把它交给网关：

1
我 → 默认网关 → Internet

📡 DHCP：IP、网关、DNS 是怎么来的

大多数时候，这些网络参数不是我手动填写的，而是 DHCP 自动分配的。

标准流程大致是：

1
2
3
4
[客户端] → Discover
[DHCP服务器] → Offer
[客户端] → Request
[DHCP服务器] → ACK

DHCP 通常会一次性下发四样关键配置：

1
2
3
4
IP 地址
子网掩码
默认网关
DNS 服务器

所以一台电脑能不能正常上网，往往不只是看有没有 IP，而是看这整套配置有没有完整拿到。

🚨 为什么 169.254.x.x 基本等于上不了网

这次最明显的异常是以太网拿到了这样一个地址：

1
169.254.255.214

这类地址叫 APIPA，也就是 Automatic Private IP Addressing，通常意味着 DHCP 失败了，系统没拿到正式配置，只能先给自己生成一个临时地址。

结果就是：

1
2
3
4
❌ 没正确拿到网关
❌ 没正确拿到 DNS
❌ 只能在非常有限的链路本地场景里通信
❌ 基本无法正常访问互联网

所以 169.254.x.x 不是“网络还行，只是地址有点怪”，而是比较明确的故障信号，不是一套真正可用的正式网络配置。

🌐 DNS：域名不是网络的起点，只是翻译过程

访问域名时，中间还有一步翻译。

系统先要查 DNS：

1
google.com → DNS 解析 → 142.x.x.x

拿到 IP 之后，才会进入真正的路由和传输过程。

所以 DNS 本身也是一次网络请求。如果 DNS 出了问题，通常会出现这样的现象：

1
2
ping 8.8.8.8 能通
ping google.com 不通

这说明链路本身还在，但“名字翻译”这一步挂了。

🧩 Tailscale 到底是怎么插进系统网络的

Tailscale 看起来像“多出来一张网卡”，本质上是因为它做了三件事：

1
2
3
1. 创建虚拟网卡
2. 写入针对 tailnet 的路由
3. 在需要时接管 DNS

可以画成这样：

1
2
3
4
5
                 普通互联网流量
应用程序 ───────────────→ Wi-Fi → 路由器 → Internet
    │
    │ 访问 100.x.x.x / tailnet 设备
    └──────────────→ Tailscale 虚拟网卡 → 加密隧道 → 对端设备

如果是 Split Tunnel 模式，那么数据路径可以压成：

1
2
普通流量      → 仍然走 Wi-Fi
Tailscale流量 → 只走 Tailscale

我这台机器当前更接近这种工作方式。

如果开启了 Tailscale 的 DNS 管理，那么 DNS 请求也可能改成：

1
DNS 查询 → Tailscale → 上游解析器

如果没有接管，DNS 仍然会走本地网络里的原始解析器，通常就是路由器或手动配置的 DNS。

MagicDNS 则是在这个基础上提供一个更好记的名字，例如：

1
device.tailnet.ts.net

这样我就不用硬记 100.x.x.x 这种地址。

🔍 回到我的真实案例

现在再把前面的概念带回我的机器，结论就比较清楚了。

Wi-Fi：正常

1
2
IP:       192.168.5.40
Gateway:  192.168.5.1

这说明它成功拿到了完整的 DHCP 配置，所以能正常上网。

Ethernet：异常

1
2
IP:       169.254.x.x
Gateway:  无

这个状态基本可以直接下结论：

1
DHCP 失败 → 没拿到正式网络配置 → 无法正常上网

问题大概率不在浏览器，也不在整个系统协议栈，而在以太网这条链路本身。

Tailscale：正常

1
2
IP:   100.72.x.x
路由：100.x.x.x → Tailscale

这说明 Tailscale 的虚拟网卡和相关路由是正常的。它不是导致以太网故障的直接原因，而是系统中的另一条独立网络路径。

🧪 如果以太网拿到 169.254.x.x，应该怎么排查

如果只看现象，我现在最合理的判断是：

不是“浏览器坏了”，而是以太网接口没能完成从 DHCP 获取正式网络配置的流程。

这个流程压缩一下就是：

1
2
3
4
5
6
7
8
9
10
11
网卡链路建立
   ↓
客户端发 DHCP Discover
   ↓
DHCP 服务器回 Offer
   ↓
客户端发 Request
   ↓
DHCP 服务器回 ACK
   ↓
拿到 IP / 网关 / DNS

而 169.254.x.x 往往意味着这条链路中间断掉了，系统只能退回 APIPA 自分配地址。

先用一个最小判断树切责任域

1
2
3
4
5
6
7
8
9
10
以太网 = 169.254.x.x
        ↓
DHCP 没成功
        ↓
┌───────────────────────────────┐
│ 1. 物理链路没通？              │
│ 2. Discover 没到 DHCP 服务器？ │
│ 3. DHCP 回包没回来？           │
│ 4. 本机没正确接收或应用配置？   │
└───────────────────────────────┘

这四类问题基本就覆盖了大多数排障场景。

第一层：先看是不是链路本身有问题

先确认最底层是不是通的：

  • 网口灯是否正常亮起或闪烁
  • 换一根网线
  • 换一个交换机端口
  • 如果用了扩展坞、USB 网卡或转接器，先怀疑它

如果连链路协商都没成功，那么 DHCP 广播根本发不出去，后面所有排查都没有意义。

第二层：确认是不是只有这台机器有问题

最快的做法不是先深挖协议，而是做交叉测试：

1
2
同一根网线 + 别的机器
同一台机器 + 别的网线 / 别的端口

结果通常能直接把责任域切开：

  • 别的机器也拿不到地址：更像网络侧问题
  • 只有这台机器拿不到地址：更像本机网卡、驱动或系统问题

这一步的价值很高，因为它能避免我一开始就在错误方向上死磕。

第三层：看本机有没有正常发起重新获取配置

在 Windows 上，我通常会先看：

1
2
3
ipconfig /all
ipconfig /release
ipconfig /renew

关注几个信号：

  • 以太网是否显示 Media disconnected
  • 有没有默认网关
  • renew 时是否直接报错

如果 renew 就失败，说明问题通常还在 DHCP 获取链路前半段，而不是浏览器、DNS 这些更上层的组件。

第四层：确认 DHCP Client 和网卡驱动状态

再往上，就要排除是不是本机服务或驱动异常：

1
2
Get-Service Dhcp
Get-NetAdapter

这里主要看：

  • Dhcp 服务是否处于 Running
  • 网卡是否被禁用
  • 网卡是否显示异常状态或速率异常

如果设备管理器里网卡有黄色感叹号，或者禁用再启用后状态明显变化，就要优先怀疑驱动、转接器或者网卡本身。

第五层：怀疑接入网络策略，而不只是怀疑 DHCP 服务器

很多时候问题不在“DHCP 服务器挂了”，而在于包根本没走到它那里。比如：

  • 交换机端口 VLAN 配置不对
  • 端口认证没有通过
  • 实验室或办公网络限制了未知设备接入
  • 中间网络设备把广播或回包拦住了

所以更准确的说法不是“我连不上 DHCP 服务器”，而是：

我的以太网接口没有成功完成 DHCP 配置获取这条链路。

这句话更稳，因为它覆盖了链路、交换网络、DHCP 服务、本机驱动和系统服务几类可能性。

如果让我按最短路径排

我会优先按下面这个顺序来：

1
2
3
4
5
1. 看网口灯 / 换网线 / 换端口
2. 同网线换别的机器
3. 本机执行 ipconfig /renew
4. 检查 Dhcp 服务和网卡状态
5. 再怀疑 VLAN、端口认证或交换机侧策略

这样做的原因很简单：越靠前的步骤成本越低，而且最能快速切分“问题在机器上，还是在网络环境里”。

✅ 总结

把整件事压到最核心，就是：

1
2
3
4
5
6
7
8
9
10
       ┌──────────┐
       │   应用    │
       └────┬─────┘
            │
       ┌────▼─────┐
       │  路由表   │  ← 决定流量走哪
       └────┬─────┘
  ┌─────────┼─────────┐
  │         │         │
Wi-Fi   Ethernet   Tailscale

网络不是“连上 Wi-Fi 就结束了”。

真正决定数据能不能走通的，是下面这些因素共同作用的结果：

  • 网卡是否正常工作
  • DHCP 是否成功发放参数
  • 默认网关是否存在
  • 路由表是否把流量送对地方
  • DNS 是否能把域名翻成 IP
  • VPN 是否插入了额外路由和解析逻辑

最后可以把它总结成一句话：

网络不是“连上就完事”，而是网卡、路由、DNS 和协议栈共同构成的数据流系统。

🚀 后续还能继续挖什么

如果我想把这篇继续扩成系列，后面可以接这些主题：

  • ARP：电脑怎么找到默认网关的 MAC 地址
  • DNS 递归解析：域名到底怎么一步步查出来
  • WireGuard / Tailscale 原理：隧道和密钥是怎么工作的
  • Windows WFP：安全软件和 VPN 如何拦截流量
  • 多网卡策略路由：为什么有时“连着两个网却更容易出问题”

如果我想要的不只是“会用网络”，而是“看懂系统为什么会这样决策”，那么这条理解路径是有用的。