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

去好好解决报错。这种取巧办法只会让 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 的应用也可以实现联网。

二手的 Android 手机就可以的

不高端吧，那就把 3.x 给替换掉吧

两台都需要关。从你给的信息看，大概率是 192.168.1.2 的没关 nat 导致的，检查检查 192.168.1.2 的防火墙跟 nat 配置

请关闭内网 nat