iOS / macOS 已经将 H3 即 QUIC HTTPS 应用到基本上系统各个组件，而第三方 App 调用系统 API 时会在发起 A 或 AAAA 请求后再次发送一个 QType 65 请求，即 HTTPS DNS Lookup ，一般情况下 H3 需要从 http/1.1 或 H2 升级，而服务器是否允许升级除了 Header 外还可以通过 QType 65 查询的方式，因为 QUIC 流量本质是无状态的 UDP ，难以被深度包检测，所以有些用户使用干净的 DNS 访问 Facebook 的时候能够通过未被硬阻断 TCPMUX 的 H2 或 QUIC 的 H3 无墙访问，最近一年大陆已经不再劫持 QType 65 查询，但是很多 DNS 过滤软件和手机上复杂的 Rule-based 代理软件等各自处理 DNS 请求的方式和回应的方式均不一致，苹果在 DNS 服务器返回错误内容的时候也没有正确处理，这可能可以解释为什么有些人将 DNS 模式改为 Fake IP 后比一般模式下使用更快。
某些 DNS 过滤软件和代理软件在某些用户定义的规则下将 QType 65 请求阻止，而且阻止的方式不是通过 SOA 或者 REFUSED ，而是 SERVFAIL ，问题就出在这里，苹果只认 QType 65 回复 NOERROR 或者 SOA ，其它情况下如 QType 65 超时，REFUSED 或者 SERVFAIL ，很多情况下不会回落到 http/1.1 ，这就会导致某些情况下 App 或者访问的网页龟速，甚至直接出错，这种激进或头脑简单的策略并不能防止中间人，某些公司网络内为了监控员工行为会一刀切阻止 QUIC ，更有甚者直接拦截 QType 65 ，这会导致很多本来没有被阻止的 App 或网站访问异常缓慢，因为应用始终在等待服务器回应，而策略一般是丢包，回应根本不存在，最后只会超时被迫回落，这是最好的情况，最差的情况是很多 assets 在正在尝试升级 H3 的请求队列之后，这会导致网络看上去非常卡。
包括 SSR++ 在内的 OpenWrt 插件也仍然在采用简单粗暴的 DROP ，这会导致客户端超时响应，在很多情况下尤其是 IM 类 App 内卡顿严重。
https://github.com/fw876/helloworld/blob/8ab6c0141bcb9abe757e6327157e9057389b642d/luci-app-ssr-plus/root/usr/bin/ssr-rules#L241
有些苹果用户也许没有注意到这个现象，这是因为苹果有个自带的 DoH ，这个 DoH 在大陆没有被封，有时候这个 DoH 线路龟速会引起其它问题，它在 WiFi 和蜂窝网络中的设置叫做 Limit IP Address Tracking ，这个选项是默认启用的，如果能够连上你的出口会变成 Anycast 最近的 Akamai 出口的 DNS ，对于广移来说是香港，不知道是否 Apple 全权控制。
对于桌面用户，可以前往如 chrome://flags/#enable-quic 禁用 QUIC 则可以避免浏览器发起 QType 65 查询然后尝试升级 H3 。
开启 QUIC 的应用会发出 QType 65 请求
只有回复 NOERROR / SOA 苹果才能正确处理
大陆不再劫持 QType 65
向伊朗不存在的 DNS 服务器发起 QType 65 查询反而被 GFW 注入返回了 A 记录
