安装发现 greasyfork 是打包以后的 artifact ，去 git 仓库里也没有找到源码，仓库里提交的也是打包以后的 artifact ，
https://github.com/zyronon/web-scripts/blob/master/V2Next.user.js

如果不打算公开源码，建议显式告知用户，并更改 license 不要用 GPLv3 。（使用任何 license 是你的自由，没有要求你公开源码的意思）

@eh5 你认为 nat64 是限制性应用场景，我解释 xlat 能兼容所有 nat44 的场景;你认为 nat64 对家庭用户比双栈网络没有连通性和速度方面的提升，我告诉你事实上是有，很多用户双栈网络的连通性和速度还不如 ipv4 only ，他们关于禁用 ipv6 的帖子搜索引擎一搜一大把。对了，作为一个 side effect ，nat64 还能让你不用为了实现 hairpin 而把所有内网入站连接都从外部网卡绕一圈，你认为这种做法没问题那就没问题吧，记得告诉你的用户在防火墙中允许来自公网接口的入站连接以及相应的 security implication 。

当然你认为以上都是 off topic ，“没有看到你的侧重点单方面输出”，没有问题，是否实现或以什么优先级实现 nat64 是你的自由，我并没有要求你做什么，其他问题跟用户说去吧，本帖不用再回复。

@eh5 说道性能，还有一个值得考虑的问题。现在常用的家用嵌入式路由器的 cpu 根本无法支持高带宽场景下的 nat ，而是 offload 到专用硬件处理。考虑到这种硬件应该是负责重写包而不是负责连接追踪，实现支持 hw offload 的 fullcone nat 应该是可能的，只不过能否通过 ebpf 就不知道了。不然的话，很可能受限于嵌入式设备的性能而让用户的带宽严重降低。

@eh5 你说的对，内部网络之间（非同一子网）的 p2p 应用确实需要最外层的 nat 网关支持 hairpin ，这是我之前忽略了的情况。但 nat 就是这样的 hack ，开启了 hairpin 会 break 某些应用，关闭了 hairpin 会 break 另一些应用。是否需要 hairpin 取决于具体需求，比如现在大部分家庭用户都是无公网 ipv4 （意味着 hairpin 发生在最外层的运营商 cgnat 上）+公网 ipv6 （对任何 sane 的 p2p 应用都是首选），实现 hairpin 的意义就不是那么大。
hairpin 最大的问题是 snat ，snat 会丢失源地址信息，当你收到一个入站包的时候，你必须 remotely 知道你要转发的目的主机到源主机之间的路由是否还经过你，才能决定是否进行 snat ，这很难正确的实现，你只能假定一些简单的网络拓扑下的情况。
具体到通过策略路由把目的为本机的包强行发到外部接口上，这已经 break 了其他所有人预期的行为，而你无法提前知道和测试所有的使用场景。比如本机端口冲突、多实例多地址个外部接口和类型（ eth/pppoe/wireguard/其他基于 tun 的代理程序）的动态路由场景，动态 ipv4/ipv6 地址。并且这会让所有目的的为该地址的入站包全部发送到外部网卡再转发回来，那么本来从内网入站的包源网卡成了外部网卡（并且经过两遍 netfilter ），正常系统都会默认的允许内网入站、禁止外网入站的防火墙规则也就 break 了。更不用说如果内网接口都是 virtio 的虚拟网卡，这种转发会非常严重的降低性能（这还没有考虑 ebpf 本身的开销，在嵌入式设备上应该也是不可忽略的）。
我觉得既然因为网卡上的 ebpf 无法捕获发往本机的包，那干脆直接让用户态的服务 reserve 所有活跃记录中的端口，然后对 hairpin 的请求直接在用户态转发，这样也能解决端口冲突问题（其他程序没有办法得知 nat 使用了哪些端口）。

NAT64 并不是限制性应用场景，646xlat 不同于 nat64 ，它是无状态的静态重写。对于支持 464xlat 的终端，并不会 break 任何除了 nat44 已经 break 的应用，唯一的 regression 就是网关有没有实现 fullcone 。当我说所有现代设备，我指的是所有面向消费者的设备，所有可以插 sim 卡的系统都必须实现 464xlat （因为很多运营商的移动数据已经是纯 ipv6 了），包括 windows/android/ios ，linux 没有把它做到开箱即用确实 behind 了。对于不支持的设备，它们不太可能依赖内嵌 ipv4 的应用，这些设备要么压根根本不需要公网联通，要么可以在纯 ipv6 环境工作。
如果你考虑连通性方面的好处，那么毫无疑问增加 ipv6 的 adoption 是对每一个 p2p 用户都有好处的。ipv6 现在的状态已经达到了只要你是接入 isp 的就已经普及了，没有的都是本地网络不支持（云厂商/企业/家庭网络用户自己），去搜一下会发现用户自己禁用 ipv6 的原因，像什么卡/打不开网页禁用 ipv6 就好了，都是因为复杂度或某些系统实现的问题（没错，又是 android ），而这些问题在纯 ipv6 环境下却可以解决和避免。如果以后因为缺少一个 fullcone 的 nat64 实现（上游那些生活在公网 ip 非常充裕的国家的人不太可能去支持）而 block ipv6 的 adoption 的话，对 p2p 应用绝对是不好的，用户希望能够同时拥有 ipv4 fullcone 和 ipv6 gua 的连通性。从端到端连通性的角度来看，fullcone 的 nat64 比 nat44 更 canonical ，毕竟打洞总是 hack ，ipv6 才是“正确”。

不过实现 nat64 确实会引入额外的复杂度，虽然在 nat44 的基础上没有额外的状态只需要一些静态重写，不熟悉 ebpf ，但是现在只有重写地址就要两千行了（可能大部分是维护状态？），再加上构造包可能会不容易，我记得几年前还看到有新闻把 rust 编译到 ebpf ，现在也没发展了。
上面回复有提到需要构造 icmp 报文返回 mtu 问题，这应该搞错了吧，分片或者返回 icmp 应该是网络栈或者网卡的事，nat 只是重写包的地址，甚至是否 EIF 都是防火墙配置的，和 nat 有啥关系。

@eh5 #19 如果我理解的不错的话，把这个 ebpf 挂载到网卡上之后，对网络栈的其他部分而言完全透明，就好像根本没有使用 nat ，来自的内网地址的包会被公网的路由器发回来一样。
这样的话 netfilter/策略路由行为应该和分配到一个公网 ipv4 网段的路由器一样，你自己维护自己的映射表，和内核的 conntrack 也互不影响，多个外部网卡运行多个实例进行策略路由的情况下应该也不会有问题。
不过这个 harpin 看起来有点太 hacky ，这样做肯定会和很多东西冲突的，比如本地监听的程序和 netfilter dnat 。对于 masquarade 而言根本不需要做这种事情，没有哪个 p2p 的应用需要从内网访问映射的端口而不是直接连接。这种事情就交给 netfilter dnat 做，只要端口不冲突应该就不会冲突，hairpin 需要进行 snat ，会让应用丢失掉源地址信息，只有特别需要的场景才会专门配置 snat ，或者在用户态使用 proxy protocol 的转发来保留源地址信息。

关于 nat64 ，最主要是能够控制 android 这种不允许用户控制、且 ipv6 实现不完整的设备在双栈环境下的行为。
纯 ipv6 网络就不要部署以 ipv4 地址作为 host 的 http 服务啊，可以用 hostname （ dns/dhcp 自动分配和解析），或者配置一个简单好输入的 ULA 地址，实在不行可以手动为需要的设备配置静态 ipv4 地址（甚至 dhcp 也行），但是不要下发路由和网关，这样依然是一个纯 ipv6 网络。访问外部的 ipv4 http 服务也不需要专门配置，现代系统会自己自动进行本地 464XLAT ，虽然多了层套娃，但这种转换对网络侧透明，不会增加复杂度。
还有一个 nat64 与打洞相关的场景，一个 p2p 应用可以监听一个 GUA ipv6 的 socket ，然后同时接收来自打洞映射的 ipv4 入站和 GUA ipv6 入站，也就是纯 ipv6 下的 p2p 应用可以无缝的、透明的和纯 ipv4 下的 p2p 应用互联。无论 ipv4 的打洞是否成功，该应用都可以接收到入站，并且在不同的网络环境不需要单独处理或配置双栈。

@eh5 #2 常见的家庭使用场景：
通过策略路由把在 netfilter 中根据元数据打了不同标记的包路由到不同的外部接口。
通过 ct 把来自外部接口发起的入站连接打标把相应的回复包从它们的来源接口发回去。
通过 ct 把来自某个 mac 地址的包打标从而能够在路由选择之前匹配到将要发送到该地址的包。

通过 nat64 能部署纯 ipv6 内网最大的好处就是简化双栈网络的复杂度，防火墙/路由/地址规则不用每个主机都重复两遍，双栈选择可以直接在 dns64 服务器中配置，不用为每个应用每个设备都单独配置，用容器跑个 p2p 应用不用修改镜像的 gai.conf （非 glibc 的应用也不一定遵守），有些系统（如 android ）直接硬编码 prefer ipv6 无法修改。
常见的 dnsmasq/adguardhome/pi-hole/dnscrypt-proxy 等转发器都内置了 dns64 的功能，不过国内的公共 dns 没一个支持 dns64 的。

这个看起来不错，但是不知道在和 netfilter/contrack/策略路由一起使用的时候会不会有未预期的行为，导致流量泄漏等问题。
其实开一个用户态的实现了 fullcone 的 socks 代理，就可以满足很多应用的需求了。
有状态的 nat6 应该是没什么使用场景的，ipv6 一般不用 nat ，即使需要 NPTv6 几乎总是最好的选项，除非你只有单个地址并且上游也是 fullcone 的。
相比之下不如整一下 nat64 ，尝试把内网完全迁移到 ipv6 only ，可以极大的简化维护成本和 p2p 连通性问题。
所有层 nat 全部都是 fullcone 的话，确实可以无限套娃，stun 打洞也能正常工作。但 upnp 那一套主动打洞协议却没有办法自动转发请求给上游，通过 stun 自己实现其中一部分协议应该是可行的。

@kyoutarou #77 只要 pcdn 和 pt 用户永远不能理解公平使用原则，自己幻想合同里没写的 7x24 跑满标称宽带是允许的，那么这种一刀切就必然会发生，自然是普通用户买单。
运营商其实真的不想限制你的用量，你用的多厂商付钱就多，更符合他们的利益。

@zhengxinhn
@czfy
从这个项目提供的功能（反吸血、自动更新 public tracker 列表）来看都是 bt 专用的，和 pt 没有任何关系，文档也声明使用 pt 时的任何行为都与上游相同。如果它在文档里的声明是真实的话，“伪装”成普通的 qbitorrent 被"tracker operator"发现是 technically impossible 的，尽管如此，它还是要教育你不能欺骗你的"tracker operator"，必须请求他们的许可才能使用，pua 入脑了才感觉不到这有多么荒诞。

@lslqtz 去看了一眼那个 issue ，请求的原因是“为了防止你这个 fork 的行为导致原版 qbitorrent 客户端被 pt 站 ban”，还是 pt 圈的 drama ，且不说 qbitorrent 的 licence 是否允许这样做，尊重上游的要求也没必要在（自己确信）行为和上游没区别的情况下不支持用户修改 UA ，这纯粹是在展示服从性。

至于这种修改对普通 bt 用户的影响(more identifiable)，似乎根本没人关心。

我说怎么更新系统镜像站老是返回 429 ，这些 xx 人的行为真是超出了想象。

另外不建议正常 bt 用户使用 qbittorrent enhanced edition ，它的 readme 里这样写：
You should ask a tracker operator to whitelist this client rather than asking a developer to change the Client Peer ID or User Agent.

PT 圈的那股 pua 的味太冲了。

不是诈骗就是洗钱，你猜不到怎么诈骗的那就大概率是后者。

@studyingss #10 如果能被认出来，说明你该换浏览器了。
这种 naive script 已经很难发挥效果了，firefox 打开 RFP 。

其实完全可以不用 pve ，pve 的功能 libvirt 全都有，直接用裸 libvirt ，再随便搭配一个前端就行了。

记得几年前 tokio 的官方 tour 就是实现一个简单的 redis server ，然而那个 demo 只涉及到 happy path ，过了一遍之后你觉得 async rust 挺舒服，直到想要自己实现 async trait 的时候，需要手写 poll/pin 就抓瞎了。

提前练好跳伞吧，高层没有其他可靠的逃生方式，基本上都是要么不用跑，要么跑不掉。

@sakisaki #1 普通消费者中有大量认为买了 AC 不去出险就是亏的，没坏也要人造“意外”去换机。

网页版/逆向的 api 都不可能可靠的。真想这样用，用正常的 pc 运行微信电脑版配合 accessibility 自行开发一套 api 勉强还算可行。