每个人都可以，
拥有SSL证书

平时做接口调试、写自动化脚本的时候，curl 报 Could not resolve host 算是挺常见的错误。说白了就是系统没法把域名转换成对应的 IP，看着简单，真排查起来原因还挺分散。

这里整理一下实际碰到过的几种情况，按顺序走基本都能定位。

最先要看的还是系统的 DNS 配置。直接 cat /etc/resolv.conf，检查里面的 nameserver 是不是有效。很多时候新装的机器或者改完网络配置，这里可能是空的，或者指向了一个不可用的内网 DNS。 临时救急的话，直接往文件里写一个公共 DNS 就行，比如 114.114.114.114 或者 8.8.8.8，执行下面这条命令：

echo "nameserver 114.114.114.114" | sudo tee /etc/resolv.conf > /dev/null

这是临时生效，重启网络或者机器后会被覆盖。

要永久改的话，不同发行版路径不一样，Ubuntu/Debian 现在大多用 netplan 配置，老版本在 /etc/network/interfaces 里改；CentOS/RHEL 则是去对应网卡的 ifcfg 配置文件里加 DNS 参数，根据自己的系统来就行。

别一上来就死磕 DNS，先确认基础网络通不通。ping 一下 8.8.8.8 这种公网 IP，如果连 IP 都 ping 不通，那问题出在网络连接本身，跟解析没关系，回头检查网卡状态、路由配置或者上游路由器。 IP 能通之后，再用 nslookup 测一下目标域名，看看能不能正常返回结果。nslookup 都解析失败的话，就可以确定是 DNS 层面的问题，跟 curl 本身没关系。

这个坑我早年踩过好几次，尤其是云服务器环境。DNS 查询默认走 UDP 的 53 端口，如果本地 iptables 规则把出方向的 53 端口拦了，或者云平台安全组没放开对应规则，哪怕 resolv.conf 写得再对也没用。 可以用 iptables -L -n 看一下本地规则，有没有限制 53 端口的条目。云服务器的话去控制台检查安全组出方向，确保 UDP 53 是允许的。

还有一种很低级但很常见的错误：本地 /etc/hosts 里写了错误的解析记录。比如之前测试的时候临时绑定过域名，事后忘了删，IP 一变就解析失败了。

cat /etc/hosts 扫一眼，有没有对应域名的条目，不对的删掉或者改对就行。

补充一个 Windows 环境特有的坑。很多人习惯了 Linux 下的写法，在 CMD 或者 PowerShell 里也用单引号包请求头参数，Windows 的命令行对单引号解析有问题，有时候也会引发类似的报错。 要么把单引号换成双引号，要么干脆直接用 Git Bash 或者 WSL 来跑 curl，兼容 Linux 语法，省得转义来转义去。

排查的时候可以给 curl 加 -v 参数，输出详细的执行过程，能看到域名解析的每一步，哪一步出问题一目了然。 也可以用 dig 或者 nslookup 单独验证 DNS 解析，如果这两个工具也解析失败，就不用在 curl 上浪费时间，直接查系统和网络配置。 如果急着验证接口本身通不通，可以用 --resolve 参数强行指定域名对应的 IP，绕开系统 DNS 直接发起请求，线上排障的时候经常用，能快速把问题定位在解析环节还是服务环节。

说起来，之前做证书自动续期脚本的时候，经常因为服务器 DNS 不稳定导致 curl 调用 CA 接口失败，证书申请卡壳。后来换成 lcjmSSL 就省心很多，它是个免费申请 SSL 证书的平台，支持自动申请、自动验证和自动部署，基于 Let's Encrypt、Google Trust Services 和 ZeroSSL 这些可信 CA，多域名、泛域名还有 IP 证书都能申，API 也简洁，不用自己写一大堆 curl 逻辑去处理 DNS 验证，能少踩很多网络解析相关的坑。

大部分情况按上面的顺序排查，基本都能找到原因。

如果是在公司内网环境，可能有内部 DNS 策略或者域名过滤规则，自己这边配置都没问题的话，联系网络管理员确认一下就行。