打开命令行，网站敲下 nslookup example.com，服务几毫秒后返回一个IP地址。器查这事看起来简单，网站但背后藏着一整套分布式数据库在运转。服务网站服务器查询，器查说白了就是网站搞清楚一个域名到底指向哪台机器、那台机器上跑了什么服务、服务响应速度怎么样。器查很多人以为这只是网站一条DNS记录的事，实际动手查过就知道，服务远没那么简单。器查

最基础的网站查询工具是 ping。它返回的服务不只是延迟数字，还能告诉你目标主机是器查否在线、TTL值大概是多少。TTL这个东西有意思，Linux默认64，Windows默认128，经过路由器转发会递减。如果你ping一个域名得到TTL=52，基本可以推断中间过了12跳。当然对方可能改了默认值，这只是一个粗略判断。

DNS查询是绕不开的一步。dig比nslookup好用得多，输出结构清晰。dig +trace example.com能看到从根域名服务器开始的完整解析链路——根服务器告诉你去问.com的TLD服务器，TLD再指向域名的权威NS，最后拿到A记录。整个过程通常几百毫秒内完成，但每一步都可能出问题。我遇到过一种情况：域名在本地ISP的DNS上解析正常，换成Google的8.8.8.8就返回NXDOMAIN。原因是权威NS上有一条配置错误，ISP的递归服务器缓存了旧记录还没过期。

拿到IP之后，下一步是看服务器上开了哪些端口。nmap是干这个的标准工具。一个典型的Web服务器，80和443通常开着，22端口看管理员心情，3306和6379这种数据库端口如果对外暴露，那基本等于把门钥匙插在锁上。我扫过一个朋友的服务器，发现8080端口跑着一个Jenkins管理后台，没设密码。这种事不少见。

查服务器地理位置用的是IP库。MaxMind、IP2Location这些数据库把IP段映射到城市级别，精度大概在几十公里范围内。但别太当真——我查过一台服务器显示在法兰克福，实际机房在阿姆斯特丹，因为IP注册地址和物理位置经常对不上。CDN节点更是如此，同一个IP可能同时服务好几个城市。

还有一种查询容易被忽略：反向DNS。用dig -x 93.184.216.34查IP对应的域名。云服务商通常会给一个类似ec2-93-184-216-34.compute.amazonaws.com的反向记录，一眼就能看出是AWS的机器。有些邮件服务器会拒绝没有反向解析的IP发来的邮件，所以这个配置在自建邮件系统时是必须的。

实际排查问题时，这些查询手段得组合着用。上个月帮人看一个网站间歇性打不开的问题：ping正常，dig解析也正常，但curl偶尔超时。最后用mtr跑了五分钟，发现到目标机房倒数第二跳有30%丢包。问题出在运营商骨干网上，跟服务器本身没关系。这种事只查DNS或者只ping一下，根本看不出来。

工具本身不复杂，关键是知道什么时候用哪个、结果怎么解读。查得多了会有一种直觉——看到TTL异常低就知道可能有负载均衡，看到多个A记录就想到轮询或故障转移，看到CNAME指向CDN域名就明白源站IP被隐藏了。这些判断没有捷径，都是一次次查询积累出来的。