@ch3n9w 不敢苟同，如果你看到的内容都不是实际的网站内容（指被浏览器修改了），你还能信任他们所谓的隐私保护吗

Web 性能的重要性： https://developer.mozilla.org/zh-CN/docs/Learn/Performance/why_web_performance#%E4%B8%BA%E4%BB%80%E4%B9%88%E5%85%B3%E5%BF%83%E6%80%A7%E8%83%BD%EF%BC%9F

@luodaoyi 杭州电信好像看地区？我家里能跑 70M 上行，下行 300M 的

举个简单的例子，比如我现在主进程里面使用 pipe 创建了一个管道，然后将输入端的文件描述符传递给 fork 出来的 A ，并在 A 中重定向输出到 pipe 的输入端，关闭 pipe 的输出端文件描述符。但我没有在主进程中关闭输入端的文件描述符并直接 fork 出了进程 B ，在 B 中重定向 Pipe 的输出端到标准输入，也在这里关闭 pipe 的输入端。那即使 A 退出了，B 中调用 read 也是会阻塞的（读不到 EOF ）。因为主进程里面没有关闭输入端的文件描述符。

正确的做法是在 fork 出 A 后在主进程直接关闭输入端的文件描述符，再 fork B ，然后再在主进程中关闭输出端文件描述符。这样能保证输入端和输出端的文件描述符仅由两个 fork 出的子进程持有。

fork 得到的文件描述符可以当作引用吧，如果不是所有的引用都断开了，并不会关闭所指向的文件描述符。（不确定是否完全正确，这两天有踩过没在主进程关闭文件描述符的坑）

@yanzhiling2001 不需要有 gui 输出，https://developer.chrome.com/blog/headless-chrome/

@spongeboBoy 找个别人分享的阿里云盘文件，转存一下，就能点亮第二个图标了（备份电脑文件可能是有 bug ，我没试过）

对，这个是故意的，之前有公告： https://developer.chrome.com/docs/privacy-sandbox/user-agent/

Debian +1

@bigdude sshd 是吧 xD:

@edis0n0 base64 一下怎么保证唯一，签名算法要做得尽量通用，不论是用 js 、Java 、go 、Python 还是其它语言。不排序如何保证最终要处理的字符串是相同的

@wangyu17455 有 ip6tables ，用 nftables 就更方便了，代理软件不是用优先域名匹配的更多些嘛，根据 sni 来对 HTTPS 流量做分流就成了。我是参考 Xray 配置的 https://xtls.github.io/document/level-2/tproxy_ipv4_and_ipv6.html#%E4%BD%BF%E7%94%A8-iptables

的确，组了台 13 代，然后在摸鱼逛 v2

https://i.imgur.com/CBPX5CL.png

应该是可行的，正常就是使用 pkcs7 pad 扩充为 16 字节的整数倍。

可以加一个 STARTTLS 端口的支持，这样也是可以用标准库进行 PlainAuth 认证的