投资的话，all in 纳指远比买北京的房子靠谱。真的以为可以一条路走到黑呀，要懂得尊重市场

这不就是 base64 编码么，只是把码表换而已。

tinyproxy 没用过么，还有 3proxy 。这些都带 http 的

软件生态支持不够。比如多媒体硬件编解码，x86 的基本上 vaapi 直接用，arm 基本上除非是 Android 否则就只能 CPU 硬扛

估计是勾上了跳过内网地址了吧

去好好解决报错。这种取巧办法只会让 bug 隐藏到运行时。内核数据结构的内存布局依赖于编译器，一个 kernel 是不允许用两个不同的编译器去编译的，除非你确定内存布局不会变。

proxy_pass https://www.baidu.com 可以改成引用的方式的比如 proxy_pass https://$1

ip a a x.x.x.11/32 dev lo

@PowerDi 可能 TCP 承载的代理不会很稳定，可以在路由器上用 gost 走 quic/kcp 类的承载转发一下。如果确认 TCP 承载是稳定的直接走代理也可以。

@elechi 我现在办法是，挂代理（ ss/ray 等），然后在代理中 hook DNS ，将 mtalk.google.com 解析到国内的 VPS/挂机宝，然后在那个挂机宝/VPS 上作中转（ UDP/udp2raw ）处理。也就是 mtalk.google.com 既不走代理也不走直连，而是单独中转。

不是有 IPv6 么

可以原地重装，不过最好虚拟机操作一遍，不然操作错误就起不来了。

@Janyd 都海外了，哪来的 DNS 泄漏一说。难道域名查询可以不通过任何域名服务器？

把锅砸了，好过总有人把锅里吃的捞干净，不给他人留点

至于 DSLITE 就是通讯行业提供的比较通用的方案，就是 IPv4 in IPv6 的方式，将 IPv4 整个报文添加一个 40 字节 IPv6 报头（协议号 4 ）来完成 tunnel 化，然后通过 v6 网络发送给 NAT 服务器。相比 CLAT 缺点是报头开销变大了，优点是实现简单，并且一般直接 linux kernel 就可以支持了，不需要应用程序去处理，cpu 开销比较小。

当然了，类似的也可以用 GRE/IPSEC 等类的 VPN 应用建立隧道达到效果，不过就是 CPU 开销变大，还有同样 MTU 下 MSS 更小。

至于双栈机器，其实电信家用宽带就可以了吧，可能上行没那么好。

@SUP7R9 CLAT 全程是 customer-side translator 是基于 NAT64 技术的双栈方案。整个技术架构叫做 464XLAT 。就是 4 转 6 － CLAT - ipv6 internet - PLAT - 6 转 4 这么个流程。大概是 android 8 以上版本都自带 CLAT 了，意思就是如果运营商支持(会通过 dns 查询 ipv4only.arpa 判断是否支持 DNS64,并查找 NAT64 的 ipv6 前缀，参考 RFC 8880)并且是 IPv6 only 的网络，那么 android 会通过开启 CLAT 来实现 IPv4 的访问，那些不支持 IPv6 的应用也可以实现联网。