Windows技巧(1)多网卡下路由和DNS配置

Windows技巧(1)多网卡下路由和DNS配置

Author: Once Day Date: 2026年3月27日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦...

漫漫长路，有人对你微笑过嘛...

全系列文章可参考专栏: 网络运维工具_Once-Day的博客-CSDN博客

参考文章:

Windows多网卡DNS设置 - 知乎

WINDOWS 10 多网卡域名解析策略配置方法-CSDN博客

文章目录

Windows技巧(1)多网卡下路由和DNS配置
- - - [1. 场景描述](#1. 场景描述)
    - [2. 解决方案](#2. 解决方案)
    - [3. 配置操作](#3. 配置操作)
    - - [3.1 网卡适配器设置](#3.1 网卡适配器设置)
      - [3.2 查看DNS与路由状态](#3.2 查看DNS与路由状态)
      - [3.3 路由添加与删除](#3.3 路由添加与删除)
      - [3.4 SSH端口转发](#3.4 SSH端口转发)
      - [3.5 防火墙规则](#3.5 防火墙规则)
    - [4. 总结](#4. 总结)

1. 场景描述

在日常办公或开发环境中，一台Windows主机同时接入两条网络的情况并不少见。典型场景是：主机通过两个以太网口分别连接家庭宽带和企业专线，家庭宽带承担日常上网、视频会议等大部分流量，而专线仅用于访问少量特定的内部服务器或受限资源。两条链路各司其职，理想状态下互不干扰。

然而，由于两条链路均通过DHCP自动获取IP地址和网关，Windows系统会同时收到两条默认路由（即目标为 0.0.0.0/0 的路由条目）。当两条默认路由的跃点数（Metric）相同或相近时，系统实际上形成了等价多路径（ECMP）的状态。此时Windows在转发流量时，可能将数据包从任意一张网卡发出，导致访问外网时走了专线、访问专线资源时却走了家庭宽带，网络行为变得不可预期。

除了路由层面的冲突之外，DNS解析同样会受到影响。DHCP服务器通常会为每张网卡各自下发DNS服务器地址，Windows的DNS客户端在发起域名查询时，可能将请求发往专线侧的DNS服务器。专线DNS往往仅能解析内部域名，无法正常解析公网域名，表现为网页打不开、域名解析超时等现象，排查起来容易与路由问题混淆。

可以通过 route print 命令来观察当前系统的路由表状态，典型的冲突路由表如下所示：

powershell 复制代码

IPv4 路由表
===========================================================================
活动路由:
网络目标        网络掩码          网关            接口           跃点数
0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.100     25
0.0.0.0          0.0.0.0      10.0.0.1         10.0.0.50         25
192.168.1.0      255.255.255.0    在链路上       192.168.1.100     281
10.0.0.0         255.255.255.0    在链路上       10.0.0.50         281
===========================================================================

2. 解决方案

整体思路可分为三个层次：首先在网卡适配器层面调整优先级，其次在路由表层面加固默认出口，最后针对特定需求灵活扩展。三者配合，既能保证日常流量稳定走家庭宽带，又能按需使用专线资源。

第一步是调整网卡适配器配置。在专线网卡的属性中，取消勾选IPv6协议栈，避免IPv6链路本地地址或路由对系统产生额外干扰。同时，将专线网卡的接口跃点数手动设置为一个较大的值（例如200或更高），使其路由优先级低于家庭宽带网卡。Windows的DNS客户端在多网卡环境下，会优先使用接口跃点数较低的适配器所关联的DNS服务器，因此这一步同时解决了DNS查询走错链路的问题，无需额外配置DNS优先级。

第二步是在路由表中添加覆盖路由，防止流量意外逃逸到专线。具体做法是添加两条永久静态路由：0.0.0.0/1（覆盖 0.0.0.0 ~ 127.255.255.255）和 128.0.0.0/1（覆盖 128.0.0.0 ~ 255.255.255.255），下一跳均指向家庭宽带网关。这两条 /1 路由在掩码长度上比默认路由 0.0.0.0/0 更精确，根据最长前缀匹配原则，所有流量都会优先命中这两条路由而走家庭宽带，即使专线侧的默认路由仍然存在于路由表中，也不会被实际选中。这一技巧在VPN分流场景中也很常见。

text 复制代码

路由匹配优先级示意：
  目标 IP: 8.8.8.8
  ├─ 匹配 0.0.0.0/0  via 专线网关   (掩码长度 0，优先级低)
  ├─ 匹配 0.0.0.0/0  via 家宽网关   (掩码长度 0，优先级低)
  └─ 匹配 0.0.0.0/1  via 家宽网关   (掩码长度 1，优先级高) ← 命中

第三步是为需要走专线的目标地址添加临时路由。由于专线仅服务于少量固定IP，使用 route add <目标网段> mask <掩码> <专线网关> 即可，这类 /24 或 /32 的精确路由掩码长度远大于 /1，自然会被优先匹配。不设置 -p 参数时，路由条目在系统重启后自动清除，适合按需临时使用的场景。

在此基础上还可以进一步扩展。通过SSH隧道的 -D 或 -L 参数，将专线侧的某台服务器作为跳板，建立SOCKS或HTTP代理端口映射到本地。随后在Firefox等支持独立代理配置的浏览器中，将代理地址指向本地转发端口。这样特定浏览器的流量经由专线出口传输，而系统全局路由和其他应用程序的流量路径完全不受影响，实现了应用级别的精细分流。

3. 配置操作

3.1 网卡适配器设置

打开Windows控制面板，进入"网络和共享中心"，点击左侧"更改适配器设置"，找到专线对应的以太网适配器，右键选择"属性"。在属性窗口中，取消勾选"Internet 协议版本 6 (TCP/IPv6)"，然后选中"Internet 协议版本 4 (TCP/IPv4)"并点击"属性"，在弹出窗口中点击"高级"，取消勾选底部的"自动跃点"，并将接口跃点数手动填写为 512。确认保存后，专线网卡的路由优先级和DNS优先级均会相应降低。

3.2 查看DNS与路由状态

配置完成后，通过PowerShell验证当前DNS解析是否已经走家庭宽带。使用 netsh 可以查看各网卡绑定的DNS服务器及其优先级顺序：

powershell 复制代码

# 查看所有接口的 DNS 配置
netsh interface ip show dns

# 查看完整路由表
route print -4

# 查看指定接口的详细信息
netsh interface ipv4 show addresses

若专线侧存在内部域名需要验证解析路径，可以使用 nslookup 指定DNS服务器进行测试。以下命令分别测试默认DNS和专线DNS的解析结果，便于确认域名查询是否按预期分流：

powershell 复制代码

# 使用系统默认 DNS 解析（应走家庭宽带 DNS）
nslookup www.baidu.com

# 手动指定专线侧 DNS 解析内部域名
nslookup uat-developer.dfem.uat 10.0.0.1

3.3 路由添加与删除

添加两条 /1 永久覆盖路由，确保绝大部分流量从家庭宽带网关出口。-p 参数表示持久化路由，重启后依然生效。其中 192.168.1.1 应替换为家庭宽带的实际网关地址：

powershell 复制代码

# 添加永久覆盖路由（需要以管理员身份运行）
route -p add 0.0.0.0 mask 128.0.0.0 192.168.1.1
route -p add 128.0.0.0 mask 128.0.0.0 192.168.1.1

# 为专线目标添加临时精确路由（重启后失效）
route add 10.20.30.0 mask 255.255.255.0 10.0.0.1

# 删除路由条目
route delete 10.20.30.0 mask 255.255.255.0

添加完成后，通过 route print -4 确认路由表的状态。重点检查两条 /1 路由是否已正确写入，以及跃点数是否符合预期。可以使用 tracert 命令实际跟踪目标IP的转发路径，验证流量出口是否正确：

powershell 复制代码

# 验证公网流量走家宽
tracert -d 8.8.8.8

# 验证专线流量走专线网关
tracert -d 10.20.30.5

3.4 SSH端口转发

通过SSH的本地端口转发功能，将专线侧服务器上的HTTP代理引入本地。假设专线可达的跳板机地址为 10.0.0.200，其上运行了一个监听 8080 端口的HTTP代理服务，使用以下命令将其映射到本地 127.0.0.1:1080：

powershell 复制代码

# SSH 本地端口转发（-L 本地端口:目标地址:目标端口）
ssh -N -L 1080:127.0.0.1:8080 user@10.0.0.200

# 若需要 SOCKS5 代理，可使用动态转发
ssh -N -D 1080 user@10.0.0.200

转发建立后，在Firefox浏览器中进入"设置 → 常规 → 网络设置 → 设置"，选择"手动配置代理"，将HTTP代理或SOCKS主机填写为 127.0.0.1，端口填写 1080。这样仅Firefox的流量经由专线隧道传输，系统其他程序不受影响。

3.5 防火墙规则

本地转发端口默认会监听在 127.0.0.1 上，通常外部无法直接访问。但若SSH命令中使用了 0.0.0.0 绑定或其他配置导致端口暴露在局域网中，则需要通过Windows防火墙添加入站规则进行限制：

powershell 复制代码

# 添加防火墙入站规则，阻止局域网访问本地 1080 端口
netsh advfirewall firewall add rule name="Block LAN Proxy Access" ^
    dir=in action=block protocol=tcp localport=1080 ^
    remoteip=192.168.1.0/24,10.0.0.0/24

# 查看已添加的规则
netsh advfirewall firewall show rule name="Block LAN Proxy Access"

# 如需删除规则
netsh advfirewall firewall delete rule name="Block LAN Proxy Access"

上述规则将来自 192.168.1.0/24 和 10.0.0.0/24 两个局域网段对本地 1080 端口的入站TCP连接全部阻断，同时不影响 127.0.0.1 本机回环访问。在实际配置中，remoteip 参数应根据两张网卡所在的子网地址段进行调整。

4. 总结

上述方案通过调整接口跃点数、添加覆盖路由、结合SSH端口转发三个层次的配置，基本实现了多网卡环境下的流量分流目标。日常使用中，家庭宽带承载绝大部分流量和DNS查询，专线仅在需要时通过精确路由或代理隧道介入，两条链路的职责划分较为清晰。从实际效果来看，该方案能够满足大多数场景的需求。

但客观而言，这套配置仍然比较粗糙。专线网卡在系统中依然处于活跃状态，DHCP租约续期时可能重新写入默认路由或DNS配置，部分应用程序在枚举网络接口时仍然能够感知到专线的存在。例如，某些视频会议软件或游戏客户端会自行选择网络出口，绕过系统路由表的优先级策略；Windows自带的网络状态检测（NCSI）也可能通过专线发送探测请求，导致系统误判网络连通性。

方面	当前状态	存在的隐患
默认路由	`/1` 覆盖路由兜底	`DHCP`续期可能刷新跃点数
`DNS`解析	跃点数控制优先级	个别程序可能直接调用专线`DNS`
专线入站流量	未做限制	专线侧设备可主动访问本机
代理端口	防火墙规则初步限制	规则覆盖面有限，缺乏出站控制

后续若要进一步加固，可以从以下方向改进。一是在Windows防火墙中为专线网卡接口配置更严格的出入站规则，仅放行已知的目标IP和端口，其余流量一律拦截，从根源上杜绝意外流量从专线进出。二是考虑将专线网卡的DHCP改为静态IP配置，手动指定地址和网关但不填写DNS服务器，避免DHCP租约变动对路由表造成干扰。三是通过Windows任务计划程序定期执行路由检查脚本，一旦发现覆盖路由丢失或跃点数异常，自动修复配置。

powershell 复制代码

# 简易路由检查脚本示例（可加入任务计划定期执行）
$route = route print -4 | Select-String "0.0.0.0\s+128.0.0.0\s+192.168.1.1"
if (-not $route) {
    route -p add 0.0.0.0 mask 128.0.0.0 192.168.1.1
    route -p add 128.0.0.0 mask 128.0.0.0 192.168.1.1
    Write-Output "覆盖路由已重新添加: $(Get-Date)"
}

总体而言，多网卡路由分流本身并非复杂的技术问题，但Windows系统在多出口场景下的行为不够透明，各类应用程序对网络接口的使用方式也缺乏统一规范。当前方案在成本与效果之间取得了一个可接受的平衡点，适合作为轻量级的日常解决方案使用，如果对隔离性有更高的要求，则需要引入策略路由或虚拟化网络等更为系统的手段来实现。

Once Day

也信美人终作土，不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发，不妨点个赞👍和关注！
(｡◕‿◕｡)感谢您的阅读与支持~~~