@wuzhewuyou react signal 表示，啊？难道这不是趋势？

Here’s a parting “TL;DR” recap: For robust NAT traversal, you need the following ingredients:

A UDP-based protocol to augment

Direct access to a socket in your program

A communication side channel with your peers

A couple of STUN servers

A network of fallback relays (optional, but highly recommended)

Then, you need to:

Enumerate all the ip:ports for your socket on your directly connected interfaces

Query STUN servers to discover WAN ip:ports and the “difficulty” of your NAT, if any

Try using the port mapping protocols to find more WAN ip:ports

Check for NAT64 and discover a WAN ip:port through that as well, if applicable

Exchange all those ip:ports with your peer through your side channel, along with some cryptographic keys to secure everything.

Begin communicating with your peer through fallback relays (optional, for quick connection establishment)

Probe all of your peer’s ip:ports for connectivity and if necessary/desired, also execute birthday attacks to get through harder NATs

As you discover connectivity paths that are better than the one you’re currently using, transparently upgrade away from the previous paths.

If the active path stops working, downgrade as needed to maintain connectivity.

Make sure everything is encrypted and authenticated end-to-end.

tailscale 会自动创建 upnp 端口映射的，所以
> 我的想法是，打洞失败，既然能连接 derp 服务器，那就能控制另一端，搞个脚本，让另一台设备主动请求 OpenWrt （ upnp/nat-pmp)开放一个临时端口。然后 tailscale 是否支持这样搞？
人家本来是这样的。

> tailscale 是暴力遍历端口（它们官网有教程），实践下来还是能够打洞成功的。
tailscale 是生日算法，并不是暴力遍历 https://tailscale.com/blog/how-nat-traversal-works
"But we can get rid of STUN, the birthday paradox trick, port mapping protocols, and all the hairpinning bumf. That’s much nicer!"

@zombiej 是的，实际上 rc 基本上也是蚂蚁的人写的，但是这种套娃的写法使得找实现和做优化修改难度剧增，很多功能都是套了好几层才暴露出来的，需要花很大力气才能搞清楚最终实现

@yuhuij #25 keep-alive 有个实验性的 activity： https://react.dev/reference/react/Activity

路由守卫什么的需要自己写

@yuhuij #13 你会发现 antd 整个基本就是 rc 的壳，几乎所有控件最终都会调用 rc-*控件

js 的对象无论是 getter/setter 还是 proxy 都是一个对象，你直接把对象给替换了，当然就无法监听变化了
ref 无论你怎么替换，实际上你置换的都是对象的.value 值。

基本上你可以理解为 ref=reactive{ value: ??? }，所以使用 ref 时，ref 对象本身永久都不会变，自然总是可以监听到变动

域名被分配到了.1 了，不过还可以正常访问。
感觉免费的就很可能会被分配过去，我从来没有用任何域名+cf 做过代理等滥用的情况，也不是新号

现在主流密码管理器的设计在服务器上存放的都是高度加密的密文，而打开密码库的主密钥从头到尾是不会在网络上传输的，即便被监听了也抓不到。但如果是访问者中了木马被记录键盘了自然就另当别论了。

@w88975 openssl 的同类替代品还是很多的，而且 openssl 本身屎山有点严重，ffmpeg 要好太多了

这个 noto 字体在 Windows 下的表现真是一言难尽，已删……

@lnbiuc 告诉你一个极为坑爹的事实：有些 ip 在 geoip 中同时属于中国和外国。
例如 163.181.23.233 ，同时属于 jp 和 cn

@lio996 #27 这个想法虽然比较少见，但是确实是完全可行的。你就这么想好了，我这个方案显然是可行的吧，只是在安全性上没有符合你的要求而已。你只需要自己写代码使用相同的逻辑，只是略去暴露端口的行为，就可以完成对应的功能了。

无非就是 local socks proxy client->ws tunnel->remote receiver->target 这个流程而已，我说的 frp 方案只是用线程的方案实现了这套流程，只不过我并不知道是否有现成的软件一站式提供了这整套的功能罢了

@lio996 #24 你 i 自己写当然是可以的，只是过程比较复杂自己研究下就是了，原理绝对是可行的。

如果是利用现有工具的话，想要不暴露到公网那不是很简单嘛，把 frpc 的 tcp 改为 stcp ，就不暴露了

当然我记得用 gost 的 rtcp 好像是可以直接实现的，不过那个东西使用难度其实比想象中的要大，因为文档实在是比较抽象，有点生涩难懂

一个可行的方案是双 frp 。
政务云上一个 frpc ，一个 frps （假设端口 888 ），外网服务器一个 frps ，假设端口为 777

政务云通过 frpc 向外网服务器暴露自己的 frps 服务为端口 999 ，这时候外网服务器的 999 端口实际上就是政务云的 frps888 了，那么代理就可以通过这个 999 端口的 frps 将自身映射到政务云本地上去了（如 666 ）。这时候政务云本地的 666 端口就是代理的端口。

gov:666 -> gov:888 -> frpc-> vps:999 -> proxy:any

其实就是官老爷专门针对微信出的政策而已。同样是 tx 的产品，企业微信就可以 callkit 也没人管

@ob 我刚要发了，这个网站非常准

https://www.piliapp.com/actual-size/cm-ruler/

@shiyidi 已经存在的连接可以继续通信但无法抓包。新的连接无法建立，因为支付宝高版本开启了 ssl pinning ，不接受自签证书。