服务器路由配置查询，就是查看数据报文从服务器网卡出发后即将走向的下一跳路径，这也是判断网络连不通、数据走错方向、延迟忽高忽低时最先要执行的操作。
一台服务器无论托管在机房还是运行在云端，网络能否正常通信，往往在路由表里能看出端倪，路由表好比服务器内部的交通指示牌，每一项都写明了目的网段该交给哪个网关、从哪个接口送出去，这套机制同时适用于 Linux 、Windows 以及各类交换路由设备，掌握了路由配置查询,就掌握了网络故障排查的第一个关键动作。
服务器路由配置查询的基础操作：Linux与Windows两大体系
Linux服务器路由查询命令详解
当前 Linux 服务器上主流的路由查询命令有两套：ip route 和 route -n，前者来自 iproute2 工具包，是现代内核推荐的标准命令；后者来自 net-tools，胜在参数简单,对老运维人员非常友好。
实际操作时，直接输入 ip route 即可查看完整路由表，输出内容包含几个核心字段：default 表示默认路由，via 后面的地址是下一跳网关，dev 后面是出接口名称。default via 192.168.1.1 dev eth0，含义是所有未匹配到更具体路由规则的数据包，一律交给 192.168.1.1，从 eth0 接口发出。
route -n 的输出以表格形态呈现，字段包含 Destination、Gateway、Genmask、Flags、Metric 和 Iface，Flags 为 U 表示该路由处于启用状态，为 UG 则说明带网关的静态路由，对需要写脚本自动巡检路由状态的人来说，route -n 的格式化输出更容易被 awk 或 grep 处理,适合批量提取网段和网关信息。
Windows服务器路由配置查询操作步骤
Windows Server 上查询路由有两条路径，第一条是打开命令提示符或 PowerShell，输入 route print，直接输出完整的 IPv4 与 IPv6 路由表，字段包含网络目标、网络掩码、网关、接口和跃点数，第二条路径是使用 PowerShell 的 Get-NetRoute 命令，返回对象化数据，方便用 Where-Object 做条件筛选,例如只查看某个网段或某个接口的路由信息。
相比之下，Linux 命令的输出风格更偏向文本流，Windows 命令则更结构化，两者没有本质优劣,取决于使用场景和个人习惯。
路由查询命令的对比与选用逻辑
| 查询场景 | Linux 推荐命令 | Windows 推荐命令 | 核心关注点 |
|---|---|---|---|
| 快速查看全表 | ip route |
route print |
默认路由与直连网段 |
| 脚本化巡检 | route -n 配合文本处理 | Get-NetRoute 管道过滤 | 网关、Flags、Metric |
| 验证指定目标路径 | ip route get 目标IP | Test-NetConnection | 下一跳与实际出接口 |
| 查看策略路由规则 | ip rule | Get-NetRoute -PolicyStore | 源地址策略与路由表优先级 |
如何查看Linux服务器路由配置：三组命令覆盖九成场景
检查默认路由是否指向正确网关
服务器无法访问公网，是最常见的求助场景，此时先别急着清防火墙或重启网卡，执行 ip route 看一下默认路由，正常情况下输出应该只有一条 default 条目,且网关地址与机房分配的网关一致。
部分服务器因为同时启用了 NetworkManager 和 network 服务，会出现两条 default 条目，两条条目各自有不同的 metric 值，系统依据 metric 大小优先选用数值较小的那条，如果服务器实际连接的交换机端口与默认路由的网关不在同一物理链路，数据包就会发往错误出口，外网自然不通，这时删除错误的默认路由，保留正确网关,问题即刻解除。
验证内网特定网段的路由是否缺失
业务访问不了内网网段的典型表现：服务器能 ping 通同网段的机器，但访问另一区域的机器超时，这种场景下用 ip route | grep 10.2.0.0 查看目标网段是否存在路由条目，没有输出,说明本地路由表里压根没有这个网段的路径。
顺着线索继续排查，通常是上一级核心交换机没有下发对应网段的路由，或是云平台的路由表配置遗漏了条目，手动添加临时路由后，业务立即恢复,可确认问题就出在路由缺失上。
使用 ip route get 验证实际转发路径
ip route get 192.168.30.10 是一条容易被低估的命令，它模拟一次完整的内核路由查找过程，告诉你发往该地址的数据包会从哪个网卡出去、交给哪个网关，相比肉眼逐条翻路由表，这条命令在处理双网卡或策略路由环境中效率极高，业内专家指出，这是快速验证路由规则是否生效的最直接手段,也是排查路由不对称问题时的首选工具。
路由配置查询在故障排查中的实际应用
多重默认路由冲突的处理
此前处理过一台云服务器，客户反馈外网访问时断时续，登录后执行 ip route，发现系统内存在两条 default 路由，一条指向内网网关，一条指向公网网关，原因在于云平台下发网络配置时，与服务器内部自定义网络脚本产生了并发冲突,两条路由条目被同时写入。
处理方式很直接：先删除错误的那条默认路由，再对正确的网关条目调整 metric 值，最后重启 network 服务，路由表恢复成单一条目后，外网访问随即恢复正常，这类问题在云服务器和物理机上面都会出现,排查思路完全一致。
多网卡服务器路由配置查询的难点
服务器配置多张物理网卡时，路由查询的复杂度明显上升，以双网卡接入不同运营商为例，两块网卡各自设置了网关，系统只会保留一个默认路由，另一条链路虽然存在,却几乎不承载流量。
这时候需要策略路由介入，查询策略规则用 ip rule，输出中可以看到 from 内网IP/32 lookup 100 之类的内容，表示来自某源地址的流量将查找编号为 100 的路由表，再执行 ip route show table 100，就能查看这张策略表内的详细网关信息,这种组合查询方式是多网卡路由排查必须掌握的技巧。
能 ping 通网关但外网不通的排查思路
网关 ping 通，只说明二层链路和三层本地网络是通的，外网不通时，先检查默认路由是否指向了正确的公网网关，云环境下，控制台显示的内网网关未必是服务器内部路由表里的默认网关，两者存在 NAT 转换关系较为常见。
执行 ip route get 8.8.8.8 查看实际出口路径，再对照云控制台上 VPC 的路由规则，可以快速判断是服务器侧配置问题还是云端路由策略问题，整个过程不需要重启任何服务,几分钟内就能定位。
从查询到修改：静态路由配置的完整实操流程
临时修改路由表的操作方式
临时添加与删除路由，重启后失效，适合做验证性测试,常用操作：
- 添加一条到内网网段的路由：
ip route add 10.3.0.0/16 via 192.168.1.1 dev eth1 - 删除这条路由：
ip route del 10.3.0.0/16 - 刷新路由缓存：
ip route flush cache - 验证新路由是否生效：
ip route get 10.3.0.5
命令执行后即刻生效，不需要重启任何服务，发现添加错误时，用 del 指令马上回滚,操作风险非常低。
持久化静态路由的配置方法
CentOS / RHEL 系列的操作路径是编辑 /etc/sysconfig/network-scripts/route-eth1 文件，写入 3.0.0/16 via 192.168.1.1 dev eth1，保存后执行 systemctl restart network，Ubuntu 18.04 及以上版本使用 netplan，在 /etc/netplan/.yaml 中追加 routes 段，执行 netplan apply 生效。
这两条路径都要注意：接口名必须与实际存在的网卡名完全一致，否则配置不会生效，系统也不会给出明显报错，执行
ip link show 先确认接口名称，再写配置文件,避免低级失误。
策略路由的查询与配置进阶
当服务器承载多项业务，且不同业务要求走不同出口链路时，策略路由是最优解,操作路径很清晰：
- 执行
echo "100 custom" >> /etc/iproute2/rt_tables，注册一张名为 custom 的路由表 - 执行
ip route add default via 192.168.2.1 dev eth1 table custom，将默认路由注入该表 - 执行
ip rule add from 192.168.10.5 lookup custom，让源地址 192.168.10.5 的流量走 custom 表
配置完成后用 ip route get 192.168.10.5 验证，输出信息会显示数据包已按策略路由正确引导至指定网关，值得注意的是，这里提到的策略路由在 debian 系和 redhat 系服务器上语法通用，但在持久化方式上略有差别,需要根据发行版选择对应的配置路径。
Q&A：服务器路由配置查询中的常见疑问
为什么我用 route -n 查到的路由和 ip route 差一条
这是系统工具差异导致的正常现象。route -n 来自 net-tools 工具包，部分内核版本下不展示策略路由及某些链路本地路由条目，而 ip route 源自 iproute2，与内核数据结构完全同步，输出更完整，两者出现差异时，以 ip route 的结果为准。
服务器加装第二块网卡后默认路由乱跳怎么办
典型诱因是两块网卡均配置了网关，系统启动时按网卡顺序写入默认路由，重启后可能发生变化，解决思路是只保留主用网卡的网关配置，另一块网卡剥离开接口，配合 ip rule 策略路由指定专属出口，重启后通过脚本自动加载 ip rule 规则,即可彻底规避路由漂移问题。
路由表查了但数据包仍然不通，下一步该看什么
路由表只解决数据包往哪个方向走的问题，链路是否真的通畅，还要检查两个环节：防火墙规则和 ARP 解析，执行 iptables -L -n 或 nft list ruleset 确认规则是否丢包，再用 arp -n 查看网关 MAC 地址是否正确解析，这两步检查完，问题基本能锁定在物理链路层,剩下的交由机房或运营商核实底层的连通性。
路由配置查询本身不复杂，难的是在纷繁的输出信息中快速找到异常点，多在日常工作中动手查看正常状态下的路由表，建立对默认路由、直连网段和策略路由的直观印象，真正遇到故障时自然能做到心里有数、手上有招。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/584187.html
