你所谓的最优化方式就是暴露所有未知域名到国内 dns ，并且你都没有提及这一 implication 。小白信了你这一套就成了和 clash 一样的潜在受害者。

@cnbatch #19 多个屏幕不同 dpi 的场景，和 DE/WM 基本没啥关系，wayland 下都可以为不同屏幕设置不同缩放。
问题在与应用本身，你启动一个应用，应用得自己探测当前屏幕的缩放比例;你把它的窗口移动到其他屏幕，它得自己响应这个事件绘制新的缩放比例的像素。这一点连 windows 也不是每个应用都支持的。

避开国产和“盗版”RHEL 系列的，其他的都可以用。你要是想马上把活干了，那就选 ubuntu;要是想正经使用 linux ，那就避开 ubuntu 。
要是桌面上用，那就避开所有非滚动更新的发行版。

如果你的使用场景涉及不想让其他实体知道你访问的网站，那么你就不是 clash 的目标用户。你有空抓包不如去看看代码，看了你就会知道你现在所做的这些就如同用筛子装水，漏洞百出。

@chengxiao #10 snap 就相当于官方版的一键脚本，这东西是给工作中需要操作 linux 服务器的运维和开发人员设计的，而不是给 linux 用户用的，linux 用户自然不喜欢这东西。

如果你是 linux 用户，那么使用你使用的 linux 发行版。
如果你不是 linux 用户，只是工作需要操作运行 linux 系统的服务器的运维或开发人员，那么 ubuntu 是最适合这类人的。ubuntu 整的 snap 之类的虽然没人愿意用，但是专门给这类人设计的。

OP 有用过 gnome 吗？ gnome 的 HIG(human interface guideline)对触屏、手势和键盘非常友好，应该更适合盲人用户使用。
之前在 hn 刷到帖子，他们本身就很重视 accessibility ，有专门的 funding 和盲人工程师。

js 生态可不原始，一直都是最具活力的生态。
python 现在现代的工具链就 rye 吧 https://rye-up.com/
相当于 rustup for python 。

到底谁教的用 docker 跑 openwrt ，这不是支持的使用场景。你要真的不想跑 VM ，至少用个 firecracker ，也比容器好。

@auv1107 你只需要回答：假如你确实想要偷偷上传数据，你有能力做到吗？用户使用你开发的这个工具之后，你仍然能做到吗？
如果这两个问题的答案是 true ，那么结束，观众应该都能理解什么是虚假的安全感了。

这个确实可以理解，Google 在隐私方面的名声可以说是臭名昭著，对 vpn 业务来说 google 这个品牌就是最大的负资产。

@lanlanye 你别说，因为 Google 一直弹 recaptcha 忍不了换到 DuckDuckGo ，发现 ddg 的搜索结果质量无论中文还是英文都足以替代 Google ，并且 ratelimit 非常宽松，无论 ip 多烂都能正常使用，对于使用共享 ip 的用户确实建议用 ddg 替代 google.

@auv1107 你在主贴提出的“用户担心剪贴板管理器上传数据”和你在本帖发布的这个应用（想要）解决的“其他应用未授权访问剪贴板”是两个完全无关的问题。
> 做这个开源的是因为有些人不信任闭源的剪贴板管理器
> Q：「如何在保护用户数据的同时，也让用户放心?」
> A：「现在,我有了一个初步的解决方案: 发布一款开源软件，防止系统剪贴板被滥用。」
你发布的这个解决方案并不能解决用户担心的问题，所以只提供了虚假的安全感。

如何把系统设计的你不能够访问用户数据、且能够证明你不能够访问，是你的问题。但似乎你并不了解也不想了解相关的技术。你的长篇大论一句话总结: trust me, bro.

@raptor #14 你这就想当然了，给你冲花费的来源也可能是一个为了能访问 v 站的普通 v 站用户。

@auv1107 #14 所以这个产品的目的是为了提供虚假的安全感，让本来不信任你的用户信任你，而不是消除信任你的需要(aka zero trust)。
> 为何我该相信你不会秘密上传数据？
这个问题有且只有一个答案：证明你不能。

安装发现 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 有啥关系。