Surge 2 用户路过，问几个问题：
1. Surge 3 HTTPS 解密后可以对 URL 进行代理了吗？ Surge 2 时只能对于 HTTPS URL 进行 302 和 reject，却不能让对 URL 规则代理，这不浪费资源吗？
2. Parallel Desktop、Docker 等进程可以直接被 Surge 全局增强模式代理了吗？ Surge 2 时，部分 TUN 模式（ enhanced-mode-by-rule = 1 ）能直接代理虚拟机进程，全局 TUN 模式必须虚拟机桥接。实在没精力给规则一条一条添加 enhanced-mode 来开启部分 TUN 模式。
3. Dashboard 查看时，里面还有没有 Unknown 进程，也就是说现在能不能检测出所有 root 进程？
4. UDP 代理还是只支持原版 Shadowsocks 吗？普通 Socks 代理可以被 Surge 支持 UDP 代理了吗？

提前感谢以下解答者。

把 popclip 扔了

词库联想不如搜狗。同是运输入，有些词百度竟然云不出来。还有中英混熟，也就是中文情况下输入英文，搜狗的补全更好。

@renyijiu 如果 2.4G 正常，但 5G 经常断开无法连接的话，建议调节 5G 信道高于 149。

麻烦稍微详细解释一下，针对不可信 DNS 和可信 DNS 判断的优先级，如果不可信 DNS 返回了国内 IP 且可信 DNS 返回了国外 IP，这种情况怎么处理？

另外，不应该同时对不可信、可信 DNS 返回的结果进行判断，这相当于开启了 ChinaDNS 的双向过滤。而关于双向过滤，ChinaDNS 作者曾经说过，是给特殊网络情况的人用的，不要开启。

IPv6 有没有墙无所谓，反正支持 IPv6 的站点有限。最重要的是，ISP 的 IPv6 质量和高校 IPv6 没得比。真爱生命，远离非高校 IPv6。看他们继续吹，用过的人表示手动关闭 IPv6，以免 ISP IPv6 影响爬墙体验。

@k9982874 根据这里 https://forums.adobe.com/thread/2221587 的说法：
"It's their updater and distribution mechanism. Effectively, we're just providing a DLL to Google."

Chrome 也是从 Adobe 拿货，利用自己渠道统一分发。从 Chrome 自动更新的特点来看，Chrome 目的是利用自己渠道分发 Adobe Flash 插件以便统一更新，减小旧版带来的漏洞威胁。

回归正题，IT 之家文章中表明是 FlashHelperService 作祟。目前可以视为只要对方没在动态链接库里面做手脚，就不会有问题。最好的检验方法，是拿中国版和非中国版中动态链接库内容对比一下。

@g531956119 Chrome 内置 Flash 属于专版，不属于独立 PPAPI 版，而且更新检查都是到 update.googleapis.com ，应该不会有问题。

据悉，第一个支持 HTTP/2 的 Chrome 版本为 41，发布时间为 2015 年 3 月。

怪不得今天打开 Firefox 提示要禁用掉 Stylish。貌似是因为 Send anonymous data to Stylish developers 选项默认被勾选，但是没有通知用户，Firefox 那边暂时把它加入了黑名单。MD，百度输入法干了这么多年这种事儿，怎么没见有人管。

https://www.reddit.com/r/firefox/comments/8vq7cx/stylish_browser_extension_steals_all_your/

@yanaraika #7 但好像没有公共 DNS 支持 TLS1.3 吧

自己新开几个路由追踪不就完了嘛？电信没有快的，日本、新加坡都是绕路美国。所以，美国最快。

我也是这个扩展弹页面，但是弹出来的是另外一个扩展安装页面，就是这个云图的扩展 Picloud。

第一次听说这种理由，我以为你会说 Proxifier DNS 转发在 macOS 存在问题，或者是 Proxifier 内存占用有点大之类的……

@rio 嗯，不管是 GFW 之前的污染方式——随机指向无效 IP，还是现在的随机指向不对应 IP，被污染域名解析都有可能给出境内 IP 地址。所以在根据 IP 分流，大多方案搭配 GFW List，让已统计的被污染地址直接走境外无污染 DNS 解析，以作为弥补。目前这种思路的方案包括但不限于 Dnsmasq+ChinaDNS，Unbound+ChinaDNS，Overture(配有 GFW list 黑名单)。

又仔细考虑了一遍楼主的方法，在权威 DNS 服务器位置和网站服务器位置没有绝对关系之上，针对域名是否被污染、网站位置是在境内还是在境外、负责解析的权威 DNS 在境内还是境外，组合出 8 种情况分析：1 ）被污染域名由境内权威 DNS 解析情况下，此方案无法获取正确结果，解决方法 GFW List，通过代理由境外发起解析请求； 2 ）境外网站由境外权威 DNS 负责解析时，此方案存在无法获取其国内 CDN 可能。后面这个问题，我考虑了半天并没有想到一个恰到好处的解决方法：常见中国域名白名单列表的话，好像都是针对国内网站，在这里可能不适用； EDNS-Client-Subnet 可能算是一个解决办法，要权威服务器支持，也不算完美。

@manjuprajna 我只能再说一遍，www.google.cn 不再提供搜索服务。直接访问它一次，你就明白了。

无解，因为它搜索时用的是 www.google.cn 搜索。众所周知，www.google.cn 不再提供搜索服务。

楼主说的就是自建 Recursive DNS，自己作为向权威 DNS 的请求方，以获得最优解析。不过分流实现有点问题：1 ）并不是完全不需要列表，还是要依靠 China IP List ； 2 ）权威服务器的位置和要访问网站的位置没有绝对的联系，使用境内还是境外权威 DNS 解析自己的网站完全由站长决定。

依靠权威 DNS 位置分流解析境内和境外解析不靠谱。相比来说，都是使用 China IP List/CHNRoute，ChinaDNS、Overture、Pcap_DNSProxy 这种依据解析后判断 IP 位置分流的方案更准确。

@rio 嗯，是配置繁琐了，单独 Unbound 就可以实现递归 DNS，没必要再祭出 Bind 这种重型武器。1 ） Unbound 配置注释掉所有 forward-zone，不转发的结果就是最后向权威 DNS 发起递归查询。2 ） root-hints 没必要写，13 台根服务器信息已经在 Unbound 内置了，再说根服务器信息也不会频繁变化，一般随 Unbound 更新就好了。