一事不明：代理工具是怎么解决 https 证书问题和 dns 污染问题的？

dns 远端解析

代理工具工作在传输层，即 TCP/UDP

https （应用层）是基于 TCP 的，代理工具负责把 TCP 链路打通，后续的证书什么的都走这个 TCP 通道，应用层（ https ）的业务不关心传输层（ TCP ）是怎么走的，所以不会有证书问题，代理服务器也无法监听 https 密钥交换过程。

至于 DNS 解析，通常的做法是本地将域名直接发到代理服务器（远端），由远端自己解析 IP 地址并完成 TCP 三次握手连接，这种远端解析 DNS 可以防止 DNS 污染。
当然也可以本地解析 DNS ，将要连接的 IP 地址发给远端直连 IP 。

代理服务器不需要开启 DNS 服务，它只需要具备域名到 IP 的转换能力就行了（ DNS 客户端角色）

@xkwy001 感谢解惑，老哥牛逼

dns 泄露 代理解决不了。很多是系统行为，不过开启 系统代理 加上 全局规则（或者开启 doh ）。可以在 https://ipleak.net/ 测试一下

代理工具分两种

1. Client 主动通过代理协议（如 HTTP/Socks 等）连接，此时域名会被直接送入代理协议，代理协议会将其直接送往远端/或者根据代理规则进行解析，不走系统 DNS 。
2. 透明代理，此时 DNS 解析通过系统 DNS 配置处理，代理软件处理 DNS 的方式也有两种，一是劫持 DNS 请求并响应，代表作为：FakeDNS 。二是不管系统 DNS ，通过透明代理处理时，嗅探对应 TCP/UDP 流量中的域名，然后做 destOverride ，将被墙站点重定向至远端代理。

无论两种方式，均工作在传输层及传输层之下，即便是嗅探也只是 L7 读取部分内容，因此无需解决证书问题。

最后，不分前提条件让人设置 DoH ，大谈特谈 DNS 泄露的，一律当小鬼处理。你以为墙很在乎你 nslookup 了什么域名？真是搞笑

搞清楚啥叫正向代理，反向代理就行

简而言之：
Charles 篡改了通信内容，普通代理没有。
Charles 为了能抓包看明文，要破坏了加密，伪造证书搞中间人攻击。但是普通代理没在乎，看啥转啥。


不简而言之，说个场景：


A 和 B 要写信，这信都在盒子里送走，这盒子最好要上个锁，防着邮差。

于是 A 和 B 决定：

1. 正常通讯都用密码锁，安全还方便。
2. 所以，通讯之前，A 要把 密码锁的密码 发给 B 。然后他们就可以用密码锁和这个密码通信了。

问题是，这个送 密码锁的密码 的盒子，本身又该怎么确保安全？
3.于是，B 只能先把自己的，经过 ”权威机构认证的 B 专用锁” (B 的证书) 发过去，这锁的钥匙只有 B 他自己有。
4. 然后 A 收到后，就用 B 的锁，锁住里面是密码的盒子，发给 B 。
4. B 就可以用自己私人钥匙打开盒子，看到密码，接下来就可以也用 密码锁 锁住盒子来进行接下来的安全通信了。

Charles 和普通代理都是送盒子的邮差，但是有区别：
Charles 为了破坏加密，会在中途，把最开始 B 的锁换成自己配的锁，而自己则收下 B 的锁。这样，A 会用 Charles 的锁来锁盒子。A 想出的密码这下邮差 Charles 就能知道了。Charles 也可以假装 A 给 B 发一个自己编的密码。

Charles 可以对通信为所欲为，这样加密就完全被破坏了！

然而 A 发现 Charles 调包过的锁觉得不对劲，这锁也没经过权威机构认证啊，看起来绝对不是 B 的，我不接受！于是他停止了发信 (报个错)，B 也迟迟没收到来信所以这事情就没了下文。

(以上是过度简化且不准确的 TLS-RSA ，就不提 dhe 系列了。反正证书被换了就不该有下文。)


而普通代理该送啥就送啥。根本懒得看里面是啥，也压根没碰过。
管你是 https 还是 DNS ，还是什么锁，反正有东西我都送走就是了。

这里最大的区别就是：Charles 篡改了通信内容破坏加密，但是普通代理没有。


最后，你可以 root 后导入你 Charles 的证书到系统证书里。运气不好的话你可能遇到了 SSL Pin. 我之前用 Xposed 模块解决的这个问题。

楼上说的很对，补充一点：代理服务器并不需要开启 DNS 服务器，想想你平时上网也没有开 DNS 服务器。代理协议把域名送到远端之后，软件就像平时上网一样，往各个公共 DNS 请求解析了

@restkhz 很清晰，我没意识到这两者差别，代理服务器压根不需要去看请求里面的内容，多谢老哥解惑