问题描述

• 现象: 同样的请求到网关地址192.168.66.61:8760，服务器请求正常，mac开发服务请求超时无响应

• 目标端口: 9999

• 初始怀疑: 隧道或路由配置问题

排查流程

第一阶段：初步抓包分析

第二阶段：排除FRPC影响

• 关闭frpc服务后问题依然存在

• 证实问题不是由frpc造成

第三阶段：发现Tailscale

• 通过ip link show发现Meta接口和tailscale0接口

• 确认Tailscale是问题根源

第四阶段：对比测试

关键证据：抓包对比

Tailscale开启时的抓包结果（问题状态）

Tailscale关闭后的抓包结果（问题解决）

根本原因分析

Tailscale造成的问题

1. 网络接口冲突：
• Tailscale创建的Meta接口干扰了正常路由
• 部分流量被错误地路由到Tailscale网络

2. NAT转换问题：
• 源IP被转换为198.18.0.1（Tailscale网络IP）
• 破坏了正常的网络通信路径

3. 路由表污染：
• Tailscale修改了系统路由表
• 导致部分请求走了错误的网络路径

为什么会出现两个不同的目标地址？

• 负载均衡器(192.168.66.61:8760)配置了多个后端

• 一个后端指向192.168.66.58:9999（正常）

• 另一个后端指向172.168.30.89:9999（可能是配置错误）

解决方案

立即解决方案

1. ✅ 关闭Tailscale服务：sudo systemctl stop tailscaled

2. ✅ 禁用Meta接口：sudo ip link set Meta down

3. 重新配置Tailscale（如果需要）：
• 检查Tailscale的路由配置
• 确保不干扰本地网络通信

验证结果

• ✅ 关闭Tailscale后，所有请求都能正常完成

• ✅ 不再出现连接超时和重置

• ✅ 网络通信恢复正常

经验总结

1. 分层排查：从应用层到网络层逐步排查

2. 抓包分析：tcpdump是定位网络问题的利器

3. 接口检查：虚拟网络接口可能是问题根源

4. 对比测试：开启/关闭服务前后的对比最能说明问题

路由优先级信息记录

当前路由表

完整路由表信息

备注

• 物理接口的优先级 (metric 100) 确保其优先处理数据包.

• 虚拟接口 在正常情况下不干扰物理网络.

路由优先级信息记录

验证时间

路由优先级分析

当前主路由表

Tailscale相关路由信息

网络接口状态

Tailscale服务状态

路由优先级分析结论

正常情况下的路由优先级

1. 物理网络接口 (enp5s0): metric 100 - 最高优先级

2. Docker网络 (docker0): 仅处理容器内部通信

3. Tailscale网络 (tailscale0): 使用独立路由表 (table 52)

问题状态时的路由冲突

• Meta接口 (DOWN状态): 虽然处于关闭状态，但仍在路由表中

• NAT转换问题: 198.18.0.1 地址导致的路由混乱

• 路由表污染: Tailscale路由规则影响了正常流量

最终猜想验证