【求教】DNS防泄漏 vs 服务卡顿,鱼与熊掌真的不能兼得吗?

日常环境:iPhone + MacBook,Shadowrocket,国内电信家宽,主要访问ChatGPT、Claude这些AI服务。
折腾经过:
一开始为了防止DNS泄漏,把国外服务全部配置成 force-remote-dns(域名解析强制走代理服务器那边查,不让本地ISP看到query了什么域名)。原理很简单:走远程解析,ISP就看不到你要连哪个域名,同时也能避开国内DNS污染返回错误IP的问题。
翻车了:
配上之后发现 ChatGPT 用起来卡得离谱,聊天时断断续续、加载慢半拍,体感明显比不加 force-remote-dns 差一大截。Claude倒是没这个问题,同样开着远程解析,一切正常。
排查下来的原因:
ChatGPT背后是Cloudflare+Azure混合CDN架构,一个页面同时连一堆不同子域名(主站chatgpt.com、静态资源oaistatic.com、人机验证arkoselabs.com、埋点statsigapi.net、功能开关launchdarkly.com、语音功能livekit.cloud等等),而且这些CDN域名的TTL(DNS缓存时长)设得很短,过期就得重新解析。force-remote-dns 意味着每次重新解析都要"发给代理服务器→代理服务器帮忙查→查完传回来"走一趟完整往返,比本地查询多了一整趟经过代理节点的延时。子域名一多、TTL一短,重新解析的频率就高,这个开销不断叠加,表现出来就是断断续续的卡顿。Claude的子域名少、TTL没那么激进,所以没这个问题。
目前的临时处理:
只给 Claude/Anthropic 保留 force-remote-dns,其他包括ChatGPT在内的全部改回本地DNS+普通代理。后来又琢磨了一版折中方案:把每个服务拆成"核心域名"(登录/主站,比如chatgpt.com本身)和"基础设施域名"(图片/统计/验证码这些走量大、TTL短的),只保护核心域名,基础设施域名放开走本地DNS——这样至少ChatGPT主域名还有基本的防污染保护,又不至于因为一堆高频重连的CDN域名拖慢体验。
卡在这的困惑:
这个折中方案说到底还是没有真正解决"既要防泄漏、又要不卡"这个根本矛盾,只是把矛盾的影响范围缩小了。有没有大佬遇到过同样的问题、有更彻底的解法?比如是不是该考虑给这类短TTL域名单独做静态IP绑定(锁死解析结果,不用每次都查)、或者换一个UDP转发能力更强的代理节点来抵消这个额外往返的开销、又或者压根就有别的技术手段我没想到?蹲一个思路。