个人使用目前选择续费 google workspace ，clouflare email routing 后备。

@monkeyWie 是需要协议栈，可用现成的，比如 lwip ，还需要做一些修改以支撑侦听整个地址空间。

tunnel to socks ，如果使用 lwip 实现 tcp 流重组，关键部分是让 lwip 支持绑定侦听整个地址空间，正好做过一个，自认为代码还算清晰，供参考：

lwip: https://github.com/heiher/lwip
tcp bind all: https://github.com/heiher/lwip/commit/7d1d2d9549aa31d560049b0e1a10255488e4e94f
udp bind all: https://github.com/heiher/lwip/commit/7b341df481499a19be825f6720fbe57272860996

socks5-tunnel: https://github.com/heiher/hev-socks5-tunnel

上次办了张移动卡，出省就触发了反诈停机，10086 主动致电办理了重新复机。

HKG IPv4 终于恢复了……

分享移动直连 CF-HKG 的 IPv6 地址:

2606:4700:f1::
2606:4700:83b0::

PING 2606:4700:f1::(2606:4700:f1::) 56 data bytes
64 bytes from 2606:4700:f1::: icmp_seq=1 ttl=53 time=44.6 ms
64 bytes from 2606:4700:f1::: icmp_seq=2 ttl=53 time=44.6 ms
64 bytes from 2606:4700:f1::: icmp_seq=3 ttl=53 time=44.7 ms
64 bytes from 2606:4700:f1::: icmp_seq=4 ttl=53 time=44.2 ms
64 bytes from 2606:4700:f1::: icmp_seq=5 ttl=53 time=44.4 ms
64 bytes from 2606:4700:f1::: icmp_seq=6 ttl=53 time=44.3 ms
64 bytes from 2606:4700:f1::: icmp_seq=7 ttl=53 time=44.4 ms
64 bytes from 2606:4700:f1::: icmp_seq=8 ttl=53 time=44.3 ms
64 bytes from 2606:4700:f1::: icmp_seq=9 ttl=53 time=44.5 ms
64 bytes from 2606:4700:f1::: icmp_seq=10 ttl=53 time=44.7 ms
64 bytes from 2606:4700:f1::: icmp_seq=11 ttl=53 time=44.3 ms
64 bytes from 2606:4700:f1::: icmp_seq=12 ttl=53 time=44.9 ms
^C
--- 2606:4700:f1:: ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11018ms
rtt min/avg/max/mdev = 44.249/44.498/44.878/0.192 ms


PING 2606:4700:83b0::(2606:4700:83b0::) 56 data bytes
64 bytes from 2606:4700:83b0::: icmp_seq=1 ttl=53 time=50.1 ms
64 bytes from 2606:4700:83b0::: icmp_seq=2 ttl=53 time=49.3 ms
64 bytes from 2606:4700:83b0::: icmp_seq=3 ttl=53 time=49.5 ms
64 bytes from 2606:4700:83b0::: icmp_seq=4 ttl=53 time=49.9 ms
64 bytes from 2606:4700:83b0::: icmp_seq=5 ttl=53 time=49.8 ms
64 bytes from 2606:4700:83b0::: icmp_seq=6 ttl=53 time=49.6 ms
64 bytes from 2606:4700:83b0::: icmp_seq=7 ttl=53 time=49.8 ms
64 bytes from 2606:4700:83b0::: icmp_seq=8 ttl=53 time=50.2 ms
64 bytes from 2606:4700:83b0::: icmp_seq=9 ttl=53 time=50.3 ms
64 bytes from 2606:4700:83b0::: icmp_seq=10 ttl=53 time=49.5 ms
64 bytes from 2606:4700:83b0::: icmp_seq=11 ttl=53 time=49.3 ms
64 bytes from 2606:4700:83b0::: icmp_seq=12 ttl=53 time=49.5 ms
^C
--- 2606:4700:83b0:: ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11016ms
rtt min/avg/max/mdev = 49.266/49.723/50.328/0.329 ms

@microka SEA 质量不错。

扫了一圈 ipv6 也没有发现延迟小的。

@neutrinos 虽说默认解析出的 ip 都是 anycast ，但一段时间内不同 ip 地址的路由是不同的，质量不一。

@neutrinos 自选 ip

@viberconnection 印象以前看过一篇文章分析 cloudflare 的流量类业务免费提供是互相受益的，如果厂商没有明确禁止，可能还好吧 :)

@Archeb "透明网关能够把你流量走代理出去的前提是做了 NAT" 非也，iptables 透明代理不只有 nat 表，也有 mangle 表，只要流量经过网关就能捕获。 @sherlock1122 遇到的问题恰恰是流量不经过旁路由。所以 @ihipop 的方法显然是正解，通过单播向被代理的设备宣告旁路由是更高优先级的默认网关，实现流量重定向，也能做被代理设备范围的灵活控制。

@ihipop

如果考虑的是部分物理链路不稳定，可以使用多网卡 Bound 解决。对外的网络地址还是一个，数据会在多网卡上均衡。

有两个问题：
1. tcpwin=0 时，用户态 send 的数据也可以在内核的 TCP 栈上部分缓冲，缓冲空间有多大不同系统可能不同，影响判断精度不？
2. socks5 代理服务器也可以缓冲很小的，与问题 1 还是不太好区分？

或许就是 swap 吧 :-D

这东西是有线中继，还是无线？室外天线？

峰值 200mbps，稳定在 100m 没问题

如果是 HTTP 优先考虑下安全性问题