这个在哪里能办？我打 10000 和客户经理都说还没有这个套餐

template <typename T, size_t N>
size_t length(const T (&array) [N]) {
return N;
}

@hsj1992 我后来找了一些常用 stun server 的服务器地址，把他们都加入静态路由，具体是下面几个

# STUN server
# stunserver.stunprotocol.org
route 3.132.228.249/32 via "utun";
route 3.135.212.85/32 via "utun"; # STUN OtherAddress
# stun.hot-chilli.net
route 49.12.125.53/32 via "utun";
route 49.12.125.24/32 via "utun"; # STUN OtherAddress
# stun.syncthing.net
route 139.59.84.212/32 via "utun";
route 139.59.49.16/32 via "utun"; # STUN OtherAddress
route 198.211.120.59/32 via "utun";
route 188.166.128.84/32 via "utun"; # STUN OtherAddress
# stun.fitauto.ru
route 195.208.107.138/32 via "utun";
route 195.208.107.140/32 via "utun"; # STUN OtherAddress
# stun.l.google.com
route 108.177.125.127/32 via "utun";

@hsj1992
> 要使用 tg 还需要给它的 CIDR 网段写静态路由指向旁路网关一样，NAT 类型探测也会有设备直接指向 IP 而没经过 fakeip DNS 的场景？

是的。我上面的最近一条回复里也提到了：是静态路由配置不全的问题

@imKiva 不好意思，没看到最后一部分，手动忽略吧....

而且最好给出你的编译参数.....

出现这个错误多半和你用的 shell 有关。顺便建议把这一行和周围相关的代码贴出来，方便其他人分析问题：

/Users/itisummer/Downloads/OpenJDK12/build/.configure-support/generated-configure.sh: line 84

@hsj1992 tproxy 我就不清楚了，我自己没有使用 tproxy 的动机。你可以在客户端上开个 wireshark 抓包一下用 NatTypeTester 之类软件测试过程中的 stun 包。用经过 clash 和不经过 clash 的 stun server 的两种流量互相对比一下，看看哪里不一样。

@hsj1992

> 这个情况是设置因为静态路由导致的么？

99% 不是。我也使用静态路由的方式，客户端的网关均指向 ROS ，但在我的配置中得不到 FullCone NAT 的原因有两个：
1. 我的静态路由配置不完全：因为我的 DNS 对 stun server 始终返回真实 IP ，在上面的第 3 步的时候会变成直连从而测出未定义行为。
2. Clash Meta 的 tun 入站对 `conn.LocalAddr()` 的赋值存在 bug ，在我修复这个问题后，成功测出 FullCone Nat

@hsj1992 这个问题我前两天刚好在调试，阅读了一下 NatTypeTester 的源码，正好可以解答。我不清楚 PaoPaoGateway 里用的 Clash 是 Premium 核心还是 Meta 核心。Premium 核心似乎是不支持 Endpoint-Independent NAT 的（存疑），但是 Meta 核心在 tun 小节的配置里有一条 `endpoint-independent-nat: true` 设置之后就可以做到 mapping/filtering 都变成 EndpointIndependent 。

在上面的设置的基础上，从你的描述中 “终端把 IPV4 网关地址 手动设置成旁路网关 IP 地址....” 这一段可以看出，你用的核心应该已经给你做好了 EndpointIndependentNat （应该？），所以上面的内容可以忽略（打的时候没看到这一句，但是懒得删了，希望对后人有帮助）。这可能和 STUN 协议的原理有关，STUN 检测 filtering 行为的原理可以简单描述为：

1. 你向 stun server （记为 A ） 说 “请返回我现在访问你用的 IP:Port”
2. stun server 返回以下内容：
1. 你当前访问 stun server 的 IP:Port ，记为 Self
2. 给你发这条回复的 stun server 的 IP:Port ，即上面的 A
3. 另一个 stun server 的 IP:Port ，记为 B
3. 你向同一个 stun server A 发起一个请求，说 “请 改变 IP 和端口 向我发起一条请求”
4. stun server B 会向你的 Self 发送一个 stun 包，如果你能接收到，那么说明 filtering 行为是 EndpointIndependent

从这个过程中可以看出，Clash 会在第 4 步的时候用一个“之前你没有主动发起连接”的 IP 向你回包。但是我在测试的时候发现：tun 使用的 stack 不同（ gvisor 或者 system ），会有不同的回包 IP 行为，其中使用 system stack 存在 bug 。所以如果你的 PaoPaoGateway 里的 tun 用的是 system stack ，考虑切换到 gvisor 并配合 Meta 核心的 `endpoint-independent-nat: true` 再做尝试。
此外，还可以把 ROS 里的有一条 “drop invalids” 的规则里的 In. Interface. List 改成 !LAN ，我看前人的一些教程一上手就把这个规则改了，但我没测试过这个防火墙规则是否有影响，你也可以试一试。

这个问题其实非常复杂，我自己调试的时候费了不少功夫，最后还修改了 Clash Meta 核心的代码才实现了 filtering/mapping 都是 EndpointIndependent 。如果你按照上述的方法不能得到预期的结果，可以加个联系方式，我有空的时候可以帮你看看，文字我觉得很难说清楚这个过程（主要是我没有用过 PaoPaoGateway 不知道里面的细节）。

@xjx0524 1. 一般来说 mangle 表会让 fasttrack 失效，这是最主要的性能影响。在需求简单的情况下用 /routing/rules 更好，你可以把这个当成一个更弱的 mangle ，但需要注意如果两个一起用，mangle 表优先。

2. udp 流量不需要单独配置，因为 ip route 这条命令加的路由表对所有 ip 包都生效。并且 premium 和 meta 核心的 tun 都可以处理 udp 入站流量。
对于国外 IP 需要进代理的，用同样的方法加路由表就行。如果你嫌要同时在两台设备上维护相同的路由表很麻烦，可以考虑用一些路由协议，比如 ospf 或者 bgp

3. 如果你有 IPv6 策略路由的需求，方法同 IPv4 ，但 premium 核心的 tun 不支持 IPv6 入站流量，需要用 meta 内核

不推荐在策略路由下用这种带有包装的 clash 例如 openclash/shellclash 是因为：它们的配置是给一个路由器透明代理的最傻瓜级解决方案。

但是在你有正确的 DNS 分流和 fake ip 之后，很多 shellclash/openclash 中的配置（例如什么打标记，tproxy 转发，53 端口放行云云）就不再需要了，因为策略路由已经完成了同样的事情。那么此时再让这些包装工具带上这些规则，只会增加调试难度，并且可能在你意想不到的地方带来问题。

@imKiva 我目前就在用同类方案，没有发现除了 TG 以外的 IP 直连的主流应用

对于 Telegram 这类，用同样的方法

/ip/route add distance=110 gateway=旁路由 IP dst-address=<TelegramIPCIDR> routing-table=main

都用策略路由了就不需要在分流机器上用 openclash/shellclash 了。直接在“旁路由”上跑 clash 核心开 tun 模式和 fake ip ，然后 ip route add 198.18.0.0/16 dev utun

从目前你的描述来看，ROS 上也不需要用 mangle ，更不需要 “to_op 的默认网关为旁路由”。一种性能更好的方法是：直接往 main 表里加一条 198.18.0.0/16 下一跳为旁路由的地址。但是你需要注意不能让你的机场域名被解析成 fake ip ，否则流量会成环。不过也可以用另一张路由表，假设叫做 bypass ，然后所有 src ip 为旁路由的流量走 bypass 表，bypass 表里的默认网关为 pppoe-out1 之类，再加上几条局域网的地址网关为 bridge 口就行。命令大概类似这样：

/routing/table add fib name=bypass

/routing/rule add src-address=旁路由 IP table=bypass

/ip/route add distance=1 gateway=pppoe-out1@main dst-address=0.0.0.0/0 routing-table=bypass
/ip/route add distance=1 gateway=bridge@main dst-address=192.168.0.0/16 routing-table=bypass

然后 main 表上把 fake ip 导向旁路由

/ip/route add distance=110 gateway=旁路由 IP dst-address=198.18.0.0/16 routing-table=main

手机上靠印象打的，可能不太对，你自己弄的时候善用 tab 补全就好了

IPv6 PMTU?

nas 的网关是 openwrt 还是 tp ？
如果是前者，试试在 tp 里的端口转发里让下一跳是 openwrt ，然后在 openwrt 里再设置端口转发到 nas

我没有用这种常驻 http 服务器的形式。我的方案是把 subconverter fork 到一个私有仓库，然后配置好订阅链接，用 GitHub Actions 每天自动更新订阅并且把更新完毕的配置文件推送到 gists 。客户端只要从 gists 导入配置并设置自动更新就行