今天在使用 php 的 curl 函数时，发现需要等待大概 5 秒才能得到结果，实在是太慢了。而同样一个 url 使用浏览器访问，则立刻可以获得页面。后来又发现，即使不用 php，使用 Linux 下的原生命令 wget 去获取网页，也很慢。这真是太奇怪了，看上去不是程序的原因，而是网络设置的问题了。
执行 wget 时可以明显看到，阻塞发生在 DNS 域名解析的部分。
$ wget www.myproject.com
--2012-06-18 12:17:30-- http://www.myproject.com/
Resolving www.myproject.com... # 此处停滞约 5 秒
192.168.1.187
Connecting to www.myproject.com|192.168.1.187|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: index.html?
[ ] 5,200 --.-K/s in 0s
2012-06-18 12:17:35 (264 MB/s) - index.html saved [5200]
我使用的是开发环境，域名解析到一个内部 IP 上。奇怪的是，我使用 ping www.myproject.com 却很快可以获得 IP 地址并返回 ICMP 报文。为什么 wget 的 DNS 解析会这么慢呢？www.2cto.com
Google 到 StackOverflow 上面也有很多人提这个问题，有说是 reverse DNS 反向域名解析的问题，有说要在 host 文件中添加那个域名……都无法解决我的问题。百思不得其解之际，突然想到上周是 IPv6 日，我们运维发过一封邮件说公司网络已经全部 enable IPv6 了。会不会是这个原因呢？按照这个线索去查，果然，豁然开朗了。
$ wget -4 www.myproject.com
瞬间就返回了结果。看来是运维没有帮我们为这个域名绑定一个 IPv6 的地址，整个网络升级后，默认会优先解析 IPv6，在那个 domain 没有 IPv6 的情况下，会等待 IPv6 解析失败 timeout 之后才按以前的正常流程去找 IPv4。
对于 PHP curl 来讲，只需要加上下面一句即可解决延迟问题：
curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );
现在很多服务器都开启了 IPv6 却没有路由，无法真正工作，反而导致一些不可预料的问题。深切地体会到 IPv6 路漫漫啊……