那么在用户数和访问规模不变的情况下，NAT4 只需要更少的端口，自然也就只需要更少的 IP 地址呀

NAT1 下，CGNAT 侧公网 IP:端口同一时刻只能服务于一个用户，所以为了防止一个用于过多占用端口资源，通常采用端口分配数量和会话数量约束。而 NAT4 下，一个公网 IP:端口只要不是连接相同的目的 IP:端口，也就是 4 元组不完全相同，同一时刻是可以在多个用户间复用的。那么在

从技术上来说 NAT4 应该是可以做到最节省公网 IP 的吧，也就是在精确 4 元组匹配下能做到最大能力的 IP 地址复用，与 NAT1 相比，必然就需要更精确细化的会话记录来支撑，这可能不利于 CGNAT 的硬件加速实现。所以这里认同 @viberconnection 的观点，谁来讲讲浪费公网 IP 的具体机理？

笑死，pcdn 不会走 ipv6 吗，那下一步还要把 ipv6 关了？不改变为市场化定价机制从根源上解决问题，天天挖空心思搞这些歪门邪道~ 还真以为是创新呢

自用推荐，适用于没公网 IP 的场景，openwrt 22.03 直接 opkg 安装：

使用 NATMap 在 NAT-1 私网 IP 宽带上部署 SSH 服务: https://github.com/heiher/natmap/wiki/ssh

使用 NATMap 在 NAT-1 私网 IP 宽带上部署 FRP 服务: https://github.com/heiher/natmap/wiki/frp

使用 NATMap 在 NAT-1 私网 IP 宽带上部署 WireGuard 服务: https://github.com/heiher/natmap/wiki/wireguard

是这个吧: https://github.com/heiher/hev-fsh/blob/master/src/hev-fsh-client-term-connect.c#L72-L74

@cheneryme 正常。只能收到客户端的 TCP SYN 报文，抓包才可见，TCP 连接是建立不起来的，所以应用层也是感知不到的。

我记得阻断的不是入站，而是出站。也就是家宽上可以收到目的端口是 80 的 SYN 报文，但响应的报文客户端收不到。

MIUI 做这么做，其实都不如 AOSP……

最后这图并不是访问数据页吧，而是访问某一级页目录项，指针类型宽度是 32 位。

https://github.com/heiher/natmap/wiki/NATMap
适合你，openwrt 直接 opkg install natmap

Java 内存模型没有要求对象引用在其它线程可见，其字段的默认值的赋值写一定也是可见的。并且 OpenJDK 的实现也是这样的，除非打开那个实验性开关启用对象安全构造。

特殊的是只有对象的 final 字段才一定在对象引用可见之前完成赋值写，有显式的内存屏障实施这一约束。

@mikewang

平常并不使用 BT 协议，也不了解 BT 协议，但 mike 兄讲的很清晰，我看懂了，哈哈。

我之前从直觉上的认知与 @ysc3839 一样，认为 BT 客户端可以将自己正在侦听的公网 IP 、端口交换给 peer ，那么在本机:A —> 路由器:B —> 公网:C 三层结构下，BT 客户端通过 UPNP 或 NATPMP 打通路由器:B —> 本机:A 的入站，再利用公网侧 CGNAT 的 NAT1 特点，同时打通公网:C —> 路由器:B 。就能完全实现用户免配置。

现在综合看事实可能不是这样的，那么向开源的 BT 客户端提交补丁可能是一劳永逸的方法？增加获得并报告公网侧 IP 、端口的支持。

对于不修改 BT 客户端的情况，mike 兄的方法已经实测可行了，只要在 Natter 的 Hook 脚本中调用 BT 客户端 API 更改侦听端口即可。而对于没有 API 的 BT 客户端，不知道是不是可以实现一个代理程序来篡改客户端上报的端口 :P

@hqt1021 如果确认没有透明代理的话，有一种可能是因为 GFW 并没有在 tcp 流重组后做内容搜索，而是独立检查每个分片，macos 由于某种原因使得 host 落在两个分片中，从而匹配不上。

公网 ipv4 总之不长久了，如果是要跑服务还是使用 ipv6 或者 ipv4 打洞吧。

nat1 打洞后外部访问和公网 ipv4 几乎一样，只是 ip 和 port 双动态。如果是 http 服务 redirect 或套上可以自定义源站端口的 cdn ；如果是其它服务，将 ip 和 port 写到动态域名的 aaaa 记录是一种方法，但要求客户端支持，比如 natmap 这样： https://github.com/heiher/natmap#ip4p-address
wireguard-android 的客户端支持： https://github.com/heiher/wireguard-android

@molezz765 这个地址有没有遇到会断开的不稳定情况？

网卡硬件 offload 不支持 vlan 模式。

@molezz765 HKG 直连的地址不多了吧，这个实际能用吗？

@hqt1021 没有过透明代理吧？:P 看来墙的位置确实后移了，我这移动宽带如果加 google.com 的 Host 则 100% Reset 。