最直接线索是：能ping通、tcpdump抓到syn包但应用层无响应，且dmesg无nf_conntrack或tcp丢包提示；此时查rp_filter值为1，且存在“请求从eth1进、回包从eth0出”的异步路由，则基本确认是rp_filter严格模式导致静默丢包。
怎么确认是 rp_filter 导致跨网段访问丢包
最直接的线索是：能 ping 通、tcpdump 能抓到进来的 SYN 包，但服务端应用层完全没响应（netstat -ant | grep SYN_RECV 无新增，ss -tn state syn-recv 为空），且 dmesg 里没有 nf_conntrack: table full 或 TCP: drop open request from 这类明确提示。
这时立刻查 rp_filter 状态：
-
cat /proc/sys/net/ipv4/conf/all/rp_filter—— 全局设置 -
cat /proc/sys/net/ipv4/conf/eth0/rp_filter、cat /proc/sys/net/ipv4/conf/eth1/rp_filter—— 各网卡单独设置（注意替换为实际接口名）
如果值是 1（严格模式），且你正遭遇“请求从 eth1 进、回包从 eth0 出”的异步路由场景，那基本就是它了。
rp_filter=1 为什么在双网卡跨网段时特别容易出问题
Linux 默认用全局路由表选出口，不绑定入口网卡。比如：
- 客户端
192.168.10.5访问服务器192.168.20.100（配在eth1） - 服务器收到包后，查路由表发现去
192.168.10.5的最佳路径是走eth0（默认路由），于是回包从eth0发 - 但
rp_filter=1要求：从eth1进的包，反向查源地址192.168.10.5的最佳出口也必须是eth1—— 显然不满足，包被静默丢弃
这种“进≠出”的路由行为在单网卡+默认路由时不会触发问题，但在多网卡分网段部署（如办公网/业务网分离）时非常典型。
临时验证用 rp_filter=2（宽松模式）是否解决
别直接关（0），先切宽松模式快速验证：
-
echo 2 > /proc/sys/net/ipv4/conf/eth1/rp_filter—— 只改接收流量的那块网卡（比如eth1是业务网口） - 再试一次跨网段连接，如果立即恢复，说明就是
rp_filter逻辑拦住了 - 注意：
rp_filter=2不要求回程走同一网卡，只要求源 IP 能通过任意本地接口路由出去（即存在有效反向路径），比1松得多，又比0多一层基础校验
这个操作无需重启、不中断现有连接，适合线上快速定位。
长期配置要注意策略路由和 rp_filter 的协同
宽松模式只是绕过问题，不是根治。真要稳定运行，得让“进”和“出”在逻辑上匹配：
- 给业务网段（如
192.168.20.0/24）配独立路由表，用ip rule基于源地址或入接口做策略路由 - 确保该表里有指向
eth1的默认路由，这样回包自然走eth1 - 此时可安全设回
rp_filter=1，既安全又符合预期 - 千万别只改
all/rp_filter，而忽略具体网卡的值——内核优先用接口级配置，all只是兜底
真正容易被忽略的是：rp_filter 对每个接口独立生效，且严格模式下它不看策略路由表，只查主路由表（main）的“最佳出口”。所以即使你配了策略路由，rp_filter=1 仍可能误判。
