大家有没有遇到过这种场景：网络环境明明是IPv4和IPv6双栈，设备也拿得到IPv6地址，可实际用起来却感觉网页加载变慢、视频卡顿，甚至某些网站直接连不上。我在给内部网络做优化时反复遇到过这种情况——明明IPv4链路一切正常，系统却偏偏优先尝试IPv6，连接超时之后才切回IPv4，白白浪费好几秒。这篇文章就专门聊一个很实用的需求：在IPv6环境下如何让系统优先使用IPv4，而不是默认跟IPv6死磕。
内容涵盖三块：一是系统为什么会默认偏爱IPv6，这是根源；二是Windows、Linux、macOS三大系统分别怎么配置“IPv4优先”；三是浏览器、命令行工具等应用层的调整方法和排错技巧。无论你是帮办公室网络调优，还是自己家里路由器后面那一堆设备需要处理，这套思路都能直接用。
1. 为什么系统默认会优先IPv6
1.1 地址选择规则是“设计使然”
先解释一个很多人不清楚的点：操作系统默认优先IPv6，并不是某个厂商拍脑袋定的，而是源于RFC 6724（IPv6地址选择的规则）。这套规则里有一条核心逻辑：在同时存在IPv6和IPv4地址时，IPv6地址被赋予更高的优先级。因此，Windows、Linux、macOS在发出网络请求时，会优先尝试IPv6连接，只有IPv6连接失败并超时后，才会回退到IPv4。
这个设计初衷是推动IPv6普及——毕竟如果一个新协议永远排在后面，大家就不会去用。可是在真实网络环境里，IPv6的链路质量和覆盖情况往往没有跟上。比如运营商前缀分配异常、路由器IPv6防火墙策略过严、上游DNS对AAAA记录响应慢等，都会导致IPv6“通而不快”，或者“时通时不通”。
1.2 双栈环境下的连接流程
理解这个问题，要看一下双栈请求的完整流程：
- 客户端向DNS服务器发起解析请求。
- DNS返回的结果里既有A记录（IPv4地址），又有AAAA记录（IPv6地址）。
- 系统依据RFC 6724决定连接顺序，默认先连IPv6地址。
- 如果IPv6连接在超时时间内没有建立成功，系统才开始尝试IPv4地址。
问题就出在第3步和第4步之间。IPv6连接不成功是需要等待超时的，而这个超时时间通常在一两秒到几十秒之间。IPv6链路越是“半死不活”的状态，系统花在等待上的时间就越长。表现在用户端，就是网页转圈半天才打开，但一旦打开就一切正常——因为最终切换到了IPv4。
如果某些应用或者浏览器自己实现了更激进的连接策略，比如Happy Eyeballs算法，情况会好一些。但很多系统服务、开发工具、内网通信组件还是依赖操作系统级的地址选路逻辑。所以，在IPv6环境并不理想的前提下，让系统“优先使用IPv4”，就成了一个非常合理的操作。注意，这里说的是“优先”，不是“禁用IPv6”。真正禁用IPv6遇到一些特殊情况会更麻烦，所以优先策略更适合大多数人。
2. 操作系统层面配置IPv4优先
2.1 Windows系统下的配置方式
Windows系统里，最常用的做法是修改组策略或注册表。如果你只需要能让设备以IPv4优先，可以不用完全禁用IPv6，而是直接调整优先级。但旧版Windows（比如Windows 7和部分Windows 10版本）没有特别开放的“IPv4优先”开关，更直接的方式是调整网络适配器的高级属性或者注册表优先级权重，注册表方式相对通用一些。
具体操作为：
- 按Win+R，输入
regedit，打开注册表编辑器。 - 定位到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters。 - 在右侧新建一个DWORD（32位）值，命名为
DisabledComponents。 - 双击该值，把数值设为
0x20（这是禁用IPv6的经典设置，如果你的目标是彻底屏蔽IPv6）。但如果只想调整优先级，较新版本的Windows可以通过Network Shell的interface ipv6命令来修改各接口在地址选择策略中的优先级。
以一个较通用的情况来说，如果你在Windows 10/11上希望IPv4优先、但还保留IPv6能力，可以通过组策略实现：在“本地组策略编辑器”中，定位到“计算机配置→管理模板→网络→TCPIP设置→IPv6转换技术”，把相关策略项配置为“已启用”，并将主机路由偏好设置为优先IPv4。设置完成后用gpupdate /force刷新策略，然后断开网络重连即可生效。
不过坦白讲，在Windows这条路上，“彻底禁用IPv6”才是绝大多数人真正做的事情。如果你的目标是“优先”，我建议在系统层面不做强行调整，而是把调整放到应用层——浏览器、Git等工具都有自己的独立配置，会更精细、更好控制。很多测试工具和软件在Windows上并不严格遵循系统的IPv4优先策略，系统层改了反而会出现一些诡异的兼容问题。
我在实际调优过程中对Windows系统的建议很简单：如果这个设备几乎不依赖IPv6，直接把DisabledComponents设为0x20，干净省事；如果需要保留IPv6，就把重心放到应用层去处理，不要指望Windows系统层面能给你一个完美的“既保留又优先”的平衡。
2.2 Linux系统核心配置：gai.conf
Linux系统在实现“IPv4优先”这件事上，配置路径非常清晰，核心在于/etc/gai.conf文件。这个文件对应的是getaddrinfo()函数的地址排序规则，也就是系统API在解析域名时如何排定IPv6和IPv4顺序。绝大多数Linux软件、编程语言运行时都会走这个系统调用，所以改GAI配置可以覆盖几乎所有场景，覆盖面非常广。
默认情况下，大部分Linux发行版的/etc/gai.conf文件内容都被注释掉了，只保留默认配置。默认行为遵循RFC 6724，也就是IPv6优先。要调整成IPv4优先，核心是修改precedence表的顺序。
推荐配置如下：
# 编辑 /etc/gai.conf sudo vi /etc/gai.conf打开文件后，找到最下面的类似这样的行：
# precedence ::ffff:0:0/96 100 # label ::ffff:0:0/96 4::ffff:0:0/96这个网络段表示的是“IPv4映射的IPv6地址”，也就是IPv4流量在IPv6世界里的表达方式。precedence的含义就是优先级，数值越高越优先。默认配置里，这个precedence是50，而正常IPv6地址2000::/3的precedence是40。由于IPv4映射地址的50大于IPv6的40，所以从规则上讲，系统本来就应该优先IPv4。
问题在于，大多数Linux发行版默认把gai.conf的这行注释掉了。注释掉之后，系统就会按照RFC 3484（旧规则）把IPv6排在前面，IPv4映射地址的优先级反而被降到很低。你只需要取消注释，并给IPv4映射地址一个更高的优先级数值，即可实现全局IPv4优先。
具体做法是把这两行前面的注释符号去掉，并改成：
precedence ::ffff:0:0/96 100这里没有百分百统一的“最佳值”，但经我测试，设为100已经足够让IPv4排在所有IPv6地址前面。如果你想保留某些目标走IPv6，那就把特定IPv6前缀的precedence再调高。修改完保存退出，不需要重启系统，新的配置即时生效。你可以用下面这个命令验证：
getent ahosts www.example.com这条命令会输出解析到的所有地址，IPv4地址会优先排列在最前面，说明配置生效了。
2.3 macOS系统下的配置方式
macOS也是遵循RFC 6724规则的，但它的配置方式和Linux有些区别。macOS下调整地址优先级并不像Linux有个明面上的配置文件，而是依托于系统自带的route命令和网络设置。
实际操作中，我一般建议直接在“系统偏好设置→网络”里，把网络服务（比如Wi-Fi或以太网）的TCP/IP配置从“自动”改为“手动”，然后将IPv4配置为手动填入有效地址，IPv6留空或设置为“仅本地链路”。这样系统面对双栈环境时，因为IPv6没有可用的全局地址，就只会走IPv4了。
这本质上是通过“不给它IPv6地址”的方式达到“优先IPv4”的效果，和Windows直接禁用IPv6是同一个思路。
如果你希望保留IPv6地址、只是调整优先级，macOS下没有Linux gai.conf那么优雅的方案。之前某些场景下可以通过免费软件或自定义路由表来实现，但维护成本高，升级系统之后还容易失效。对于绝大多数macOS使用者，我这个建议很直接：如果你的网络环境里IPv6链路质量堪忧，与其纠结优先级，不如直接用上面“手动配置IPv4、让IPv6待机”的方式处理，稳定可靠，还没有副作用。
3. 应用层与命令行工具的精细化控制
3.1 浏览器的连接策略调整
浏览器是目前大多数人接触网络的主要入口，而现代浏览器都实现了Happy Eyeballs算法，能并发尝试IPv4和IPv6、取先完成连接者。很多情况下即便系统默认IPv6优先，浏览器也不会被差劲的IPv6链路拖太久。但有些浏览器版本在特定环境下表现依旧不如人意，所以手动干预依然有意义。
以Chrome和Edge为例，可以通过修改命令行启动参数来强制禁用Happy Eyeballs中IPv6优先的逻辑：在快捷方式的目标中追加--host-resolver-rules="MAP * 0.0.0.0"。这个参数的意思是强制所有域名解析结果都指向IPv4通配地址，让浏览器不再向IPv6发起连接。效果是彻底绕过IPv6，适合IPv6链路已经明显影响体验的情况。缺点是有些站点只有IPv6（纯IPv6站点），这样配置后反而访问不了——不过这类站点目前非常稀少，大多数人的使用场景不会遇到。
Firefox则有更精细的方案：在地址栏输入about:config，搜索network.dns.disableIPv6，把值设为true，只禁用DNS层面的IPv6解析。这个方式不会完全关闭IPv6，更纯粹，遇到纯IPv6站点时依然能访问。
我个人的习惯是优先使用Firefox的disableIPv6方式，保留IPv6能力但让IPv4先跑，对访问体验的伤害最小。
3.2 curl、wget与Git等工具
熟悉命令行的人会经常碰到这类问题：在服务器上用curl下载一个包，结果花了很长时间才建立连接。排除了带宽问题后，大概率又是IPv6在捣乱。
涉及这类场景，有几个实用参数：
# curl强制使用IPv4 curl -4 https://www.example.com # wget强制使用IPv4 wget -4 https://www.example.com # git指定IPv4 git -c http.version=HTTP/1.1 -c http.curlopt="-4" clone https://github.com/example/repo.git注意，wget和curl的-4参数是“只走IPv4”，不是“优先IPv4”。如果你希望它“先试IPv4、失败再试IPv6”，默认行为其实就已经是Happy Eyeballs式的了。在实测中，curl比较新版本默认就会并行尝试两个协议族取先完成的那个，体验已经很不错。如果还遇到问题，多数情况和DNS解析耗时有关，这时需要从DNS层面调整。
Git的话，git config --global http.version HTTP/1.1配合http.curlopt强制走IPv4也管用。需要说明的是，这是全局强制，可能影响国内一些托管平台的IPv6访问，但多数情况下有益无害。
3.3 npm、pip、apt等包管理器的坑
开发环境里更隐蔽的IPv6问题是包管理器。npm和pip在安装依赖时也会做DNS解析，系统按默认规则优先IPv6，如果IPv6链路延迟高，安装过程就会卡住。这个问题不像浏览器那样肉眼可见，但会影响开发效率和自动化流程。
针对这类工具，一般不用单独配置“IPv4优先”，因为它们是走系统解析的——Linux上改gai.conf一般就能覆盖。如果某个工具还是异常，可以用环境变量强制：
# 在运行命令前注入IPv4优先的网络栈变量 NODE_OPTIONS="--dns-result-order=ipv4first" npm installNode.js 17以上版本默认DNS解析顺序就是IPv4优先了，老版本需要这个环境变量。pip和apt则通常受系统gai.conf控制，gai.conf调好就不再出现卡顿。
4. 路由器与DNS侧的配合调整
4.1 路由器的IPv6开关问题
有时候你去改了系统配置，但根本问题出在路由器侧。很多家用路由器默认开启了IPv6，但实现质量参差不齐。我见过不少路由器开启IPv6后，部分数据包处理异常、MTU协商错误，导致连接成功率下降。在这种环境里，与其在每台设备上做“IPv4优先”配置，不如直接从源头控制：在路由器管理页找到“IPv6设置”，把模式改为“仅IPv4”或“关闭IPv6”。
这么做有两个好处：一是所有设备一次性收拢到IPv4，不用再一台台调；二是避免了IPv6链路半吊子带来的各种超时问题。副作用是局域网内彻底没有IPv6了，如果你没有特殊需求，这完全可接受。
如果你的路由器可以分别设置“IPv6使能”和“IPv6 DNS代理”，更精细的处理是：关闭“IPv6 DNS代理”，同时保留IPv6地址下发。这样设备虽然有IPv6地址，但DNS查询不会返回AAAA记录，应用自然就会走IPv4。这个做法相对温和，也能达到“优先IPv4”的目标。
4.2 自建DNS过滤AAAA记录
某些场景下我们不方便改动路由器配置，比如办公网络由别处统一管理，或者路由器是运营商统一提供的、不方便碰。这时候可以搭一个轻量级的本地DNS服务来过滤AAAA记录，在DNS层面实现“IPv4优先”。
方法很简单：找一台常开的小主机（树莓派、旧笔记本、软路由都可以），跑一个dnsmasq，然后配置：
# 忽略AAAA查询，即不返回IPv6地址 no-resolv server=8.8.8.8 server=8.8.4.4 # 或者更直接地过滤DNSSEC相关（视情况而定） # 关键是下面这行： filter-AAAA配置好之后，把局域网内设备的DNS指向这台小主机，所有DNS请求都会只拿到A记录，IPv4自然成为唯一选择。这个做法不中断IPv6能力，也不影响纯IPv6目标访问，是一种收放自如的优选方案。
dnsmasq的filter-AAAA配置会直接拦截IPv6地址查询，在P2P场景下可能引起一些协议问题，但在普通办公上网场景下几乎没有负面作用，环境越是复杂越推荐这种方式。
4.3 DHCPv6与SLAAC的选择
最后提一下局域网内设备获取IPv6地址的来源：路由器可能通过DHCPv6或有状态配置（SLAAC）下发IPv6地址。如果你的路由器支持单独关闭DHCPv6、只保留SLAAC，有时可以让部分设备不配置全局IPv6地址。不过这玩法偏向网络调优的高级技巧，一般家庭用户用上面的方法就足够解决问题，不用折腾到这一步。
5. 常见问题与排查技巧实录
5.1 问题排查速查表
在配置“IPv4优先”的过程中，有一些高频问题反复出现。这里整理成一张速查表，方便对照处理。
| 表现现象 | 可能的原因 | 对应处理方式 |
|---|---|---|
| 系统配置完成后IPv6连接仍然先发起 | gai.conf配置被覆盖，或应用未走系统解析 | 确认gai.conf生效；改到应用层单独配置 |
| 部分网站访问缓慢，最终能打开 | IPv6连接超时后才回退IPv4 | 调整路由器IPv6开关，或本地DNS过滤AAAA |
| 浏览器能访问，但命令行工具卡顿 | 命令行工具不走浏览器自己的Happy Eyeballs实现 | 使用curl的-4参数或修改工具配置 |
| 修改Windows注册表后设备不通 | 禁用IPv6过于彻底，导致某服务依赖IPv6 | 恢复注册表，改用组策略或应用层方案 |
| 局域网设备关了IPv6后打印机/投屏不可用 | 这些设备依赖mDNS或局域网IPv6 | 不要全局禁用，改用DNS过滤AAAA方案 |
| 修改后重启又恢复默认行为 | 操作系统更新或网络管理器重置了配置 | 加入开机自启脚本，重新应用配置文件 |
5.2 我踩过的一个坑
分享一个实际案例，给同路人提个醒。有一次在一台服务器上改了gai.conf，把IPv4优先级调高，用getent ahosts验证一切正常，可服务重启后向外发起请求依然是IPv6优先。排查了很久才发现，那个服务是用Java写的，而Java虚拟机有自己独立于操作系统的网络地址缓存和选路逻辑，根本不看gai.conf。Java里要设置java.net.preferIPv4Stack=true才会强制走IPv4。
所以，如果你发现修改系统配置对某个特定应用无效，先确认这个应用是不是自带协议栈。Java、某些SDK容器，以及部分基于Node的框架都有独立于系统的网络选路逻辑，这类环境只能在应用侧调整。
还有一些编程语言运行时会用自己的一套DNS解析和连接池逻辑，比如Java、Go在某些版本下的行为就和系统默认并不完全一致。最简单的排查手段就是临时在这个应用上强制只监听IPv4或只用IPv4发起测试，如果快速恢复，就说明是这个应用的选路问题，而不是系统问题。
5.3 最佳实战路径总结
整个配置的思路可以归纳成几条原则，按优先级选择：
- 需求是第一位的：如果你压根不需要IPv6，直接在路由器关掉它最省心。
- 如果需要保留IPv6能力：Linux优先改gai.conf，macOS优先手动配置网络，Windows则建议从应用层着手。
- 如果只影响浏览类业务：优先用浏览器自带的配置项去调整，别动系统核心设置。
- 复杂网络环境：自建dnsmasq做DNS过滤，是兼容性最好、影响面最小的做法。
以我的经验来说，真正稳定的方案往往不是那种“一刀切”的禁用，而是基于场景的精细调节。你要知道你的网络环境里IPv6到底可不可靠，再决定是禁用、优先还是保持默认。很多刚接触的朋友一上来就禁用IPv6，结果后来遇到纯IPv6资源、或者需要走IPv6的合规审计，又回来返工，这种事情我见得太多了。
对大多数人、大多数普通办公和家庭网络，建议的顺序永远是：先确认IPv6链路是否真的有问题，再决定要不要干预。如果确认要干预，优先用应用层或DNS层的方式；系统层的修改只保留在你能完全掌控的设备上。这样既能保证业务稳定，又不会给自己埋下未来的兼容性雷点。
