uni-app 无法直接控制 DNS 解析，需按 H5、App、小程序分场景干预：H5 用 预解析；Android App 可通过 luch-request 的 firstIpv4 优化；关键请求须设 timeout 并 fallback 备用域名防白屏。
uni-app 本身不直接控制 DNS 解析，但可以通过平台能力、网络库配置和前端策略绕过或缓解 DNS 慢的问题。 关键不是“在 uni-app 里写个函数解决 DNS”，而是分场景选择对应层级的干预手段——H5、App（Android/iOS）、小程序各自机制完全不同。
uni-app H5 怎么做 DNS 预解析
H5 环境走浏览器标准链路，DNS 解析由浏览器控制。最简单有效的办法是加 标签，让浏览器在空闲时提前查关键域名 IP。
- 在
public/index.html的中插入（替换为你实际用到的 API 域名）：<link rel="dns-prefetch" href="//api.example.com">
- 不要写太多，只填首屏必调的 2~3 个核心域名；多了反而触发浏览器限流
- 注意：iOS Safari 对
dns-prefetch支持不稳定，可配合preconnect双保险：<link rel="preconnect" href="https://api.example.com">
- 验证是否生效：打开 Chrome DevTools → Network → 切换到「Timing」标签，看 DNS Lookup 阶段是否明显缩短（尤其首次访问）
uni-app App（Android）怎么启用 firstIpv4
Android 平台下，luch-request 提供了 firstIpv4 配置项，能跳过 IPv6 尝试，直连 IPv4 地址，对某些运营商网络（尤其老旧 3G/4G 基站）可减少 100~300ms 的 DNS 解析抖动。
- 仅适用于 HBuilderX 2.8.0+ 编译的 App，iOS 不支持
- 必须在
http.setConfig中开启：http.setConfig((config) => { config.firstIpv4 = true; return config; }); - 不能和自定义
dns参数混用；若后端已强制返回 IPv4，该配置无效 - 真机测试时务必关闭 WiFi 用蜂窝网络测，WiFi 下效果常不明显
uni-app 怎么规避 DNS 失败导致白屏
DNS 解析失败不会抛 JS 错误，而是让 uni.request 卡在 pending 状态直到超时（默认 60s），用户看到的就是卡死或白屏。得靠兜底逻辑抢在超时前降级。
- 所有网络请求必须设
timeout，建议 8000~12000ms（别低于 5000ms，否则弱网误杀率高） - 对非核心接口（如埋点、日志上报），可设置极短 timeout（
timeout: 1000）并忽略失败 - 关键接口失败后，可 fallback 到备用域名（需服务端双域名部署）：
const urls = ['https://api1.example.com', 'https://api2.example.com']; const tryRequest = (url, idx = 0) => { return uni.request({ url, timeout: 10000 }).catch(() => idx - 慎用本地 hosts 映射方案——App 打包后无法动态改系统 hosts，仅适合开发调试
为什么改系统 DNS 对 uni-app App 没用
App 内 WebView 或原生网络模块（如 Android OkHttp）通常不走系统 DNS 设置，而是依赖运营商 LocalDNS 或内置 DNS 服务。你在统信 UOS 或手机设置里改的 DNS，只影响浏览器和部分系统应用，不影响 uni-app 打包后的独立进程。
- Android App 可通过 OkHttp 自定义 DNS 实现（需原生插件支持），但跨端成本高，不推荐常规项目接入
- 真正可控的只有：预解析（H5）、firstIpv4（Android）、备用域名（全平台）、HTTPDNS（需后端配合）
- 如果业务对 DNS 稳定性要求极高，优先推动后端接入 HTTPDNS 服务（如阿里云 HTTPDNS、腾讯云 HTTPDNS），uni-app 侧只需把域名拼成 IP+Host 方式发请求
DNS 问题最难 debug 的地方在于它不报错、不抛异常，只默默拖慢整个链路。上线前一定要在真实弱网环境（比如地铁隧道、电梯间）用真机抓包，看 Timing 里的 DNS Lookup 和 Initial Connection 是否集中出现长耗时——这才是优化起点。
