海外服务器去回程路由策略不生效，如何检查路由表并用双向测试验证？

海外服务器已经配置了源地址策略路由，但连接仍从默认网关发出，或远端能访问服务器、服务器却无法正常响应，这类现象不能只靠查看一张路由表判断。排查时应依次核对实际源地址、ip rule 匹配条件、规则指向的路由表，再用带源地址的路由查询、双向探测和抓包确认实际数据包。

海外服务器去程和回程线路有什么区别？为什么海外服务器路由需要双向测试？关键在于明确测试发起端：远端节点到服务器，反映远端及中间网络到达服务器的方向；服务器到远端，反映服务器本地如何选择出口以及远端是否能收到响应。两向路径可能不同，单独执行一次 ip route get 或 traceroute，都不足以证明端到端通信和服务器策略路由已经符合预期。

本文以 Linux 服务器、IPv4、基于源地址的策略路由为例，命令适用于安装了 iproute2 的系统。服务器地址、远端测试节点地址、网卡、网关和端口均须替换为实际值。若业务使用 IPv6，应单独检查 IPv6 规则、路由和连接结果，不能用 IPv4 测试代替。

先固定测试对象，避免把两个方向混为一谈

本文采用访问者视角定义：

• 去程：远端访问者或测试节点 → 海外服务器。
• 回程：海外服务器 → 远端访问者或测试节点。

不同服务商或运维团队可能采用服务器视角命名，把服务器发出的方向称为“去程”。因此，记录测试结果时不要只写“去程正常”，还应写明测试发起端、源地址、目标地址、地址族、协议和端口。

两向路由由不同设备和路由决策共同决定。远端发往服务器的初始数据包，主要受远端节点及中间网络影响；服务器收到请求后，服务器自己的规则和路由表参与选择返回路径。服务器上的源地址策略路由通常不能改写已经从远端发出的初始路径。两向经过不同接口、网关或中间跳点，也不一定代表故障。

因此，服务器上执行 ip route get 只能检查服务器侧的路由选择，不能单独证明远端到服务器的路径。验收应同时包含远端到服务器、服务器到远端的测试；当查询结果与连接表现不一致时，再用抓包确认真实报文。

开始前，固定一个允许测试且地址明确的远端节点，并记录服务器源地址、网卡、网关、自定义路由表编号、测试协议和端口、测试时间、节点网络环境及工具版本。一次测试只代表该节点、目标地址、协议和时间点的结果，不能据此推断所有访问者在其他时间的路径。

先采集状态。以下命令只读取信息：

date -Is
uname -a
ip -br addr
ip -4 rule show
ip -4 route show table all

如果业务使用 IPv6，再单独执行：

ip -6 rule show
ip -6 route show table all

修改前保存原始状态，便于对比和恢复：

STAMP=$(date +%Y%m%d-%H%M%S)

sudo sh -c 'umask 077; {
  date -Is
  echo "### ip -br addr"
  ip -br addr
  echo "### ip -4 rule show"
  ip -4 rule show
  echo "### ip -4 route show table all"
  ip -4 route show table all
} > /root/route-check-'"$STAMP"'.txt'

该命令会在 /root 下创建仅限管理员读取的记录文件，不修改路由。IPv6 状态需要时另行保存。

由外到内检查：地址、规则和路由表

核对业务实际使用的源地址

多公网地址服务器上，策略可能针对 198.51.100.10，而业务进程实际使用 198.51.100.11。此时即使自定义路由表内容正确，针对前一个地址的规则也不会匹配业务连接。

查看地址与主路由：

ip -4 addr show
ip -4 route show

重点确认策略所需地址确实配置在服务器上、接口符合预期，且默认路由和直连网段没有误指向其他接口。随后用实际源地址模拟一次路由查询：

SERVER_SRC='198.51.100.10'
REMOTE_IP='203.0.113.20'

ip -4 route get "$REMOTE_IP" from "$SERVER_SRC"

输出通常会包含目标、下一跳、接口和源地址，例如：

203.0.113.20 via 192.0.2.1 dev eth0 src 198.51.100.10

示例地址仅用于说明格式，不能直接照搬。若输出的 src 不符合业务要求，先核实应用是否绑定了其他地址、内核实际选用了哪个源地址，以及规则的 from 条件是否对应真实报文；不要先把问题归因于线路。

检查规则条件、优先级和实际查表顺序

Linux 根据 ip rule 的优先级依次处理路由查找。优先级数值较小的规则通常先处理。查看完整规则：

ip -4 rule show

常见结构如下：

0:      from all lookup local
100:    from 198.51.100.10 lookup 100
32766:  from all lookup main
32767:  from all lookup default

逐项核对：

1. 源地址是否匹配：from 198.51.100.10 不会自动覆盖服务器上的其他地址。
2. 规则是否指向预期表：lookup 100 指向编号为 100 的表，须与实际配置一致。
3. 优先级是否符合预期：如果自定义规则排在 main 表查找之后，而主表已经为目标提供了有效路径，主表可能先返回结果。
4. 是否还有其他匹配条件：fwmark、iif、oif、uidrange 等条件，会影响实际匹配。没有带上相应条件的查询，可能无法模拟业务报文。

规则存在不代表规则命中。必须把规则中的源地址、标记、接口等条件与实际业务流量逐项对应起来。系统用于本机地址的 local 规则也不能为了调整优先级而随意删除或覆盖。

确认规则所指向的表有可用路径

分别查看相关自定义表、主表和全部路由表：

ip -4 route show table 100
ip -4 route show table main
ip -4 route show table all

常见异常包括：自定义表为空；表内只有直连路由、没有通往目标的路径；默认路由的网关无法经对应接口到达；路由指向错误网卡；同一表内存在多个默认路由，实际选择受 metric 等属性影响；或者规则指向的表编号与添加路由时使用的编号不一致。

若策略表没有为目标提供可用路由，路由规则可能继续处理后续规则，最后由主表给出路径，也可能返回不可达。因此，“ip route get 最终仍能返回结果”不等于自定义表已经生效。还要确认输出使用的接口、网关和源地址是否与策略预期一致。

路由表名称映射可通过以下命令查看：

cat /etc/iproute2/rt_tables

名称用于阅读，内核实际使用表编号。排查记录应同时写下名称和编号，避免把不同表混淆。

用精确查询识别“配置已写入但没有生效”

仅执行以下命令可能使用内核自动选择的源地址，不能代表指定源地址的业务连接：

ip route get "$REMOTE_IP"

应使用业务源地址查询：

ip route get "$REMOTE_IP" from "$SERVER_SRC"

如果 ip rule show 中存在业务会使用的 fwmark 规则，再按实际标记模拟：

PACKET_MARK='0x10'

ip route get "$REMOTE_IP" from "$SERVER_SRC" mark "$PACKET_MARK"

只有真实业务流量确实带有该标记时，带 mark 的查询才有代表性。将查询结果按下表判断：

ip route get 只模拟路由决策，不会发出真实业务流量。它适合定位服务器侧配置，不是端到端验收的替代品。

一个典型冲突是：自定义表中已经添加默认路由，也创建了源地址规则，但规则优先级排在 main 表之后，或者源地址条件与业务实际地址不一致。按顺序检查：

ip -4 rule show
ip -4 route show table 100
ip -4 route get "$REMOTE_IP" from "$SERVER_SRC"

如果查询结果仍显示主表的接口和网关，且主表规则优先于自定义规则，优先检查规则顺序；如果源地址不匹配，则应先纠正条件。不要仅凭优先级数值就覆盖现有规则，还要检查其他规则、业务是否位于独立网络命名空间，以及测试流量是否使用 IPv6。

双向测试：分别观察到达路径和服务器出口

从远端测试节点访问服务器

在远端测试节点上，优先选择与实际业务相同的协议和端口。业务使用 TCP 443 时，可测试：

traceroute -n -4 -T -p 443 <服务器公网地址>

如果测试节点没有 traceroute，或工具不支持 TCP 探测，可在目标允许 ICMP 测试的前提下执行：

ping -4 -c 4 <服务器公网地址>

这一步观察远端到服务器的方向，可帮助判断目标是否可达，以及相关协议探测是否有响应。traceroute 中出现 * 不一定表示业务中断：部分中间路由器不回应探测报文，但仍可能转发业务流量。应结合目标端口连接结果和服务器抓包判断。

从服务器测试远端，并确认源地址

在服务器上使用策略要求的源地址：

SERVER_SRC='198.51.100.10'
REMOTE_IP='203.0.113.20'

traceroute -n -4 -s "$SERVER_SRC" "$REMOTE_IP"

如果远端节点提供可测试的 TCP 服务，且服务器具备执行相应探测的权限，可使用：

REMOTE_PORT='443'

sudo traceroute -n -4 -T -s "$SERVER_SRC" -p "$REMOTE_PORT" "$REMOTE_IP"

此方向用于观察服务器发往远端时的路径。将结果与 ip route get 和策略表对照，确认探测使用的源地址、服务器选择的接口与下一跳符合预期，并检查远端是否能收到响应。若探测失败，先区分远端不回应 ICMP、目标端口未开放、目标侧过滤、源地址不符、规则所需标记缺失或网关不可达等情况，不能仅凭一次失败认定路由表错误。

用抓包确认真实报文从哪里发出

当路由查询和业务表现不一致时，可在服务器上先开始抓包，再发起一次受控测试：

REMOTE_IP='203.0.113.20'
REMOTE_PORT='443'

sudo tcpdump -ni any -c 30 \
  "host $REMOTE_IP and (tcp port $REMOTE_PORT or icmp)"

该命令监听匹配报文的头部，不使用 -X 或 -A 查看应用内容。重点观察报文实际经过的接口、源地址、TCP 握手报文是否往返，以及返回包从哪个接口进入。

若路由查询显示应从 eth0 发出，抓包却显示业务流量从 eth1 出现，说明查询条件与实际报文条件不一致，常见原因是源地址、标记、网络命名空间或应用绑定方式不同。若抓包显示服务器收到远端发来的 SYN，而响应 SYN-ACK 从非预期接口发出，应优先检查服务器的返回路由策略。抓包中没有目标报文时，则要先确认过滤条件、接口、测试时间和测试流量是否正确。

按结果分支处理，不要靠增加默认路由试错

• 规则未命中：核对实际源地址、掩码和其他匹配条件。先确认业务使用哪个地址，再决定是否调整规则；不要贸然改成覆盖所有地址的宽泛规则，以免影响其他业务。
• 规则命中但策略表无有效路径：补查该表中的直连网段、网关和默认路径，并确认网关可经对应接口到达。不要把“规则指向该表”误当作“该表已经有可用路由”。
• 策略规则排在主表之后：核对现有规则后再调整优先级，保留 local 规则，并选择未占用的优先级。修改应安排在可回滚的维护时段。
• 路由查询正确、实际报文不一致：逐项核对业务是否绑定其他源地址、是否使用 IPv6、是否依赖标记、测试协议是否与业务一致，以及进程是否处于独立网络命名空间。先让查询条件与真实报文一致，不要通过不断增加默认路由碰运气。
• 两个方向的跳点不同：这本身不等于配置错误。判断重点是服务器是否按预期选择出口、业务连接是否完成、响应源地址是否正确，以及远端到服务器的访问是否满足业务要求。服务器侧调整通常不能改变远端发起的初始路径。

临时调整前备份，并保留明确的回滚方法

查看状态和执行 ip route get 不会修改路由；ip rule add、ip route add、ip route replace 会影响当前主机。远程操作时，错误的路由可能导致 SSH 连接中断。修改前应保存地址、规则和相关路由表，确认有控制台或带外管理入口，并核实接口、网关、源地址、表编号和现有规则。

下面仅展示临时配置的命令形式。所有变量必须替换成经核实的实际值，不能直接照抄：

SERVER_SRC='198.51.100.10'
SUBNET='192.0.2.0'
PREFIX='24'
GATEWAY='192.0.2.1'
DEV='eth0'
TABLE_ID='100'
RULE_PREF='100'
REMOTE_IP='203.0.113.20'

先检查网卡上的路由和网关可达性：

ip -4 route show dev "$DEV"
ip -4 route get "$GATEWAY"

确认直连网段、网关和接口关系后，只有在自定义表中确实缺少对应路由时，才考虑添加：

sudo ip -4 route add "$SUBNET/$PREFIX" dev "$DEV" src "$SERVER_SRC" table "$TABLE_ID"
sudo ip -4 route add default via "$GATEWAY" dev "$DEV" src "$SERVER_SRC" table "$TABLE_ID"

执行 add 前先查看表内现有条目：

ip -4 route show table "$TABLE_ID"

若路由已存在，不要重复添加。若需要替换现有路由，应先保存原值并确认影响范围；replace 会覆盖同一目标的现有路由。确认规则不存在且优先级可用后，才添加临时源地址规则：

sudo ip -4 rule add pref "$RULE_PREF" from "$SERVER_SRC/32" table "$TABLE_ID"

添加后立即复核：

ip -4 rule show
ip -4 route show table "$TABLE_ID"
ip -4 route get "$REMOTE_IP" from "$SERVER_SRC"

如果结果不符合预期，先撤销本次新增的规则：

sudo ip -4 rule del pref "$RULE_PREF" from "$SERVER_SRC/32" table "$TABLE_ID"

只有确认下列路由是本次操作新增、修改前不存在时，才按原目标删除：

sudo ip -4 route del default via "$GATEWAY" dev "$DEV" table "$TABLE_ID"
sudo ip -4 route del "$SUBNET/$PREFIX" dev "$DEV" table "$TABLE_ID"

如果路由修改前已经存在，不要执行这些删除命令，应依据备份恢复原值。不要为了验证策略而直接覆盖 main 表默认路由，这可能影响未匹配策略的连接。

验收、留证与持久化复测

一次路由策略验收至少应覆盖规则、路由表、模拟查询、真实出包和双向业务测试：

路由追踪的跳数变化、某一跳超时或中间地址变化，只能作为路径观察结果，不能单独作为业务失败依据。最终判断应优先看实际业务协议能否完成通信，并用抓包确认源地址和出口接口。

留证时记录测试时间和时区、服务器及远端节点地址、接口和网关、地址族、协议和端口、系统与工具版本，以及 ip rule、相关路由表、带源地址的 ip route get、双向测试输出和必要的报文头部。抓包文件及终端记录可能包含地址等运维信息，应按内部权限要求保存。记录中注明样本边界，例如“某测试节点、某服务器地址、TCP 某端口、某时间点”，避免把单次观测扩大为所有访问者的固定路径结论。

对比修改前后的状态可使用：

ip -4 rule show > rule-after.txt
ip -4 route show table all > route-after.txt
ip -4 route get "$REMOTE_IP" from "$SERVER_SRC" > route-get-after.txt

再与修改前保存的文件比较：

diff -u rule-before.txt rule-after.txt
diff -u route-before.txt route-after.txt
diff -u route-get-before.txt route-get-after.txt

通过 ip rule add 或 ip route add 添加的运行时配置，可能在重启或网络服务重新加载后消失。正式修复前先确认服务器使用的网络管理方式：

systemctl is-active NetworkManager
systemctl is-active systemd-networkd

再按实际管理方式检查现有网络配置中的规则、路由表和优先级。不同发行版和网络管理方式的配置方法不完全相同；未确认管理方式时，不要直接新建配置文件，也不要在只有 SSH 连接的情况下贸然重启网络服务。

持久化配置应用后，重新检查：

ip -4 rule show
ip -4 route show table all
ip -4 route get "$REMOTE_IP" from "$SERVER_SRC"

随后按相同测试节点、地址、协议和端口重复远端到服务器、服务器到远端的测试，并重新抓包确认真实接口。必要时在不同时间复测并记录结果。只有规则命中、策略表有可用路径、实际出包与查询一致、两个方向的业务测试符合预期，且配置重载后仍存在，才能完成这次路由策略验收。