sing-box项目TUN模式下strict_route配置问题解析

问题背景

在Linux系统中使用sing-box项目的1.9.x版本时，用户报告了一个关于TUN模式下的网络连接问题。具体表现为：当升级到1.9.2或1.9.3版本后，虽然日志显示RESTful API服务已正常启动，但实际上无法访问UI界面，整个网络功能也无法正常工作。而回退到1.8.14及更早版本则一切正常。

问题现象分析

用户提供的配置文件中启用了TUN模式，并设置了以下关键参数：

• auto_route: true
• strict_route: true
• inet4_address: 172.19.0.1/30
• stack: system

在1.9.x版本中，这些配置会导致以下异常现象：

1. 容器内部网络连接被阻断
2. 无法访问sing-box自身的API接口(9090端口)
3. 网络功能完全失效
4. 日志中却显示服务已正常启动

根本原因

经过排查，发现问题出在strict_route参数上。在1.9.x版本中，当strict_route设置为true时，会严格遵循路由规则，导致以下问题：

1. 自身访问被阻断：严格路由模式下，sing-box自身的网络连接也被重定向到TUN设备，形成了一个死循环
2. API服务不可达：虽然服务监听端口已开启，但外部请求无法正确路由到服务进程
3. 网络功能失效：所有网络流量都被错误地重定向

解决方案

将TUN配置中的strict_route参数改为false即可解决此问题：

{
  "type": "tun",
  "inet4_address": "172.19.0.1/30",
  "inet6_address": "fd10::1/126",
  "auto_route": true,
  "strict_route": false,  // 修改此项
  "endpoint_independent_nat": false,
  "mtu": 1500,
  "sniff": true,
  "sniff_override_destination": false,
  "stack": "system"
}

技术原理深入

strict_route参数控制着TUN设备的路由严格程度：

• true(严格模式)：

  • 所有流量强制通过TUN设备
  • 不区分本地和远程流量
  • 可能导致自身服务无法访问

• false(宽松模式)：

  • 允许本地流量直接通过
  • 保持自身服务的可达性
  • 仅重定向需要处理的流量

在1.9.x版本中，路由处理逻辑有所调整，使得严格模式下的行为更加严格，这也是为什么在1.8.x版本中可能不会出现此问题的原因。

最佳实践建议

1. 除非有特殊需求，否则建议保持strict_route为false
2. 如果确实需要使用严格路由模式，可以考虑：
   • 添加特定的路由规则排除本地服务
   • 将API服务绑定到不同的网络接口
3. 对于容器化部署，特别注意网络命名空间的影响
4. 升级版本时，注意检查路由相关参数的变更说明

总结

这个案例展示了网络工具中路由配置的重要性。sing-box在1.9.x版本中对路由处理逻辑的改进虽然提高了严格性，但也带来了与自身服务可达性的权衡问题。通过调整strict_route参数，用户可以灵活地根据实际需求平衡安全性和功能性。对于大多数用户场景，宽松路由模式已经能够提供良好的安全性和功能性平衡。