可以在 广告屏蔽扩展 的 自定义静态规则 中添加这个来使其不再拦截该请求（去掉中间的空格）：
@@||log-sdk. ksapisrv. com/rest/wd/common/log/collect/*$domain=zhihu. com

这样就可以临时解决该问题了。

@JamieChen 如果你是用 +86 手机号注册的电报，那你注册时的收的验证码短信，就已经暴露了你正在注册电报的行为了（毕竟短信内容对于运营商来说都是明文的，短信内容写的那么清楚。。。
可以确定的是运营商或者说对接的相关部门肯定会记录下来的（哪怕存着吃灰），不过也是这几年才重点关注这些的，各种严查打击，如果是好些年前注册的没啥事（毕竟头几年还能直连呢）。

@keyfunc 你可以参考这个 Issues：
https://github.com/XIU2/CloudflareSpeedTest/issues/115

也是这个人在我的项目里发了后我才注意到 mosdns 的，使用后我就顺便帮其完善了，方便新手使用。

其中我贴出了 Cloudflare CDN 自选 IP 的配置示例，其他 CDN 也就是复制粘贴重复 response_matcher 、blackhole 组合罢了，另外这个示例为了小白方便且 IP 段少，所以我是直接将 Cloudflare CDN 的 IP 段写到配置文件内了，但我自己的话是用 data_providers 来载入外部数据文件的。

@gbw1992 你好歹翻译看一下呀，这个报错是配置文件第 25 行有错误（比如 格式 什么的）

我用 mosdns 就是为了实现 CDN 优选 IP 加速访问。
目前已经实现了 Cloudflare CDN 、AWS Cloudfront CDN 、Akamai CDN 指定为优选 IP 。
唯独 Fastly CDN 比较特殊，有规律但末尾数字不同，难以直接指定为某一个优选 IP 。。。

其他 CDN 的话，平时似乎很少能碰到，就懒得去折腾了~

当然，我也折腾了一些其他需求，比如国内外分流、去广告什么的。

@totopper312 Matrix 和 Mastodon 是一个原理，都是联邦制的，即一堆网站组成联邦同盟，而用户则自己选择一个网站入住。电子邮件就是典型的联邦制，每个人选择一个邮箱服务商，而各个邮箱服务商之间是互通的，你只需要知道对方邮箱名，就能向对方发送“消息”。
[ 用户 A <=> 邮箱 A <=> 邮箱 B <=> 用户 B ]

不过 Matrix 对标的是 TG 、Discord 这类即时通讯工具。
Mastodon 和 Nostr 则对标的是 Twitter 这类社交网站。

nostr 的 Github 介绍里写了呀，只分客户端和中继服务器。
你发送一条消息，客户端会将其发送给相应的中继服务器，然后中继服务器再发送给目标用户的客户端。
[ 客户端 A <=> 中继 <=> 客户端 B ]
而中继服务器很多，也可以自建，也可以随便换，不用担心被某个中继封杀等情况。

而 Mastodon(长毛象) 的话，则是这样：
[ 客户端 A <=> 服务器 A <=> 服务器 B <=> 客户端 B ]
你的账号和信息都依托于服务器 A ，一旦服务器 A 出啥问题，就会影响到你，具体 nostr 在 Github 里提到了。

不过这些去中心化的社交、聊天工具，我都试过，但感觉多少都有点慢。。。体验有点别扭。。。

我记得 B 站有人对比过国内外视频网站的码率，国内爱奇艺最高，1080P 平均 2000 Kbps ，B 站其次，优酷更次（平均 1000 Kbps ），腾讯最差（平均 600~900 Kbps ）。
而 奈飞 平均大概 5000+ Kbps 。。。

虽说码率并不完全等于画质，但码率太低肯定会有影响的，现在哪怕是盗版资源，也大都最低 2000 Kbps 了。国内这些视频网站一边会员加价、加广告、一边降低用户体验。。。
我开会员纯粹是给家人开的，自己则很少去看。

确实，很多低端便宜的路由器都不支持关闭 IPv6 防火墙。。。

我家老路由器不支持 IPv6 后来升级千兆运营商送了一个路由器，支持 IPv6 但却无法关闭防火墙，好在我本身已经有了 IPv4 公网，因此也不是那么需要，所以还是凑活着用了。

被 SNI 阻断的域名无法加密 SNI ？

当初 gitee 也是这样干，“替”作者加速的，结果后来 gitee 就变得。。。无力吐槽了

磁力链接就是将种子文件去中心化了，解析磁力链接，和你 BT 下载其实本质是一样的。即 BT 软件通过 DHT 等方式获取拥有该 BT 种子文件的用户，并链接对方，对方将 BT 种子文件上传给你，你获得了 BT 种子文件后再解析种子开始下载资源。。。

因此，如果磁力链接解析速度慢，要么是该资源凉了，要么是你的 DHT 太捉急，要么是 BT 软件自身有缺陷（我记得很多人说 qb 解析磁力链接很慢，但我没验证过，我习惯用 BitComet 了）。

另外，一些 BT 软件可能会用服务器辅助解析磁力链接，比如迅雷（及各网盘的离线下载），解析过的磁力链接会存在它的服务器上，下次有用户解析该磁力链接时，直接返回 BT 种子文件即可。

当然是电脑网卡上的 DNS 优先级最高呀。

我这边联通，200M/40M ，升级到千兆后，就变成了：1000M/60M 。。。

Cent Browser 有个 自动复制选中文本 功能很好用，而那些不让选择文字的大都依靠 CSS 可以解决。

尝试让这三个域名走代理试试：
translate .google .com
translate .googleapis .com
translate-pa .googleapis .com

我记得以前工信部发文说了关于 APP 开屏广告的问题，要求可以关闭、只有点击指定区域才跳转等等规定，结果那段时间各大 APP 消停了一会，后来就出现这种摇一摇的 APP 开屏广告，这光明正大的打脸工信部呀。。。
搞不懂，都是怎么想的。。。

我对 iptables 了解不多，你把 -A OUTPUT 改成 -A INPUT 试试。

@edfan1221 显然是为了成本、负载考虑。
不过其实 Cloudflare 的亚洲节点，国内访问也不咋地，我这边联通扫到过：

日本节点，虽然是直连，但都是 NTT ，白天都丢包，晚上更惨。
香港节点延迟反而比日本高 20ms ，估计是回程绕日本了。
其他的，韩国、印度等地，都绕道日本 NTT 或 新加坡 NTT 或绕两个，延迟更高，丢包更严重。

目前亚洲就一个台湾的联通好点，直连延迟较低，但也不稳定，而且我这边联通还会规律阻断 Cloudflare CDN IPv4 段（只要 HTTPS 访问就可能阻断 443 端口 3 分钟整），导致我只能用 IPv6 凑合。。。
https://github.com/XIU2/CloudflareSpeedTest/issues/217
除了亚洲外，也就只有欧洲的德国节点适合联通，延迟较低（ ICMP 能低至 139ms ），但也因为阻断而...

IPv6 的话，不好扫，我也懒得去大海捞针，都是随便测速找个延迟低的凑活着用。

也就移动会好点，可以直连 香港节点，延迟很低，但是因为用的人太多，可能是超负荷了吧，经常 Re-routed ，甚至此时此刻都还处于 Re-routed 状态呢。