我做 Gitae，是因为我经常遇到同一个实际问题：网站是真的挂了，还是只是我这边有问题？
只看一个浏览器标签页，其实很难完成诊断。页面打不开，可能是 origin server 真正宕机，也可能是 DNS、HTTPS 证书、路由、防火墙规则、关闭或被过滤的端口、ISP、VPN 路径、浏览器状态或本地缓存造成的。表面症状一样，但正确的处理方式完全不同。
这就是我希望 Gitae 解决的问题：不是只给一个绿色或红色状态，而是帮助我把问题缩小到下一步真正值得调查的 layer。
“网站挂了”背后的真正问题
很多简单的 website checker 实际只回答一个很窄的问题：某个 URL 在某个时间、从某个位置有没有响应？这个结果有用，但它还不等于故障诊断。
如果 DNS 配置错误，重启应用没有帮助。如果 HTTPS 因证书问题失败，修改页面内容也没有意义。如果某个 TCP port 无法连接，server 本身仍然可能正常运行。如果网站从外部 server 可以打开，但从我的网络打不开，问题也可能出现在我的网络到目标之间的某段路径，而不是 application server。
所以我把 Gitae 建立在一个更实用的模型上：网站是一条由多个依赖组成的链，每个检查只能提供其中一部分的证据。
外部视角很有用，但不是绝对答案
Gitae 的检查运行在我位于莫斯科和赫尔辛基的 VDS server 上。这样，我就能从发现问题的电脑和网络之外获得额外的观察点。
如果网站在本地打不开，但两个 VDS 都能正常访问，这是一个有价值的信号：至少可以说明 origin 并不是对所有地方都不可达。此时我会更认真地检查本地 DNS、ISP routing、VPN、浏览器、firewall 或其他依赖具体网络路径的问题。如果远程 probe 也失败，那么 server、DNS、证书、routing 或更广泛网络故障的可能性就更值得调查。
但 remote check 并不会自动比 local check “更可靠”。两个 VDS 位置不能代表整个互联网。网站可能在莫斯科和赫尔辛基正常，却在另一个国家、ISP、CDN edge 或网络中失败。对我来说，远程结果只是额外的观测点，不是全球性的判决。
Gitae 目前检查什么
- Website check — 从外部 server 检查 URL 是否响应。
- SSL check — 检查 HTTPS/TLS 证书状态以及与证书相关的问题。
- DNS check、nslookup 和 dig — 查看域名如何解析，以及返回了哪些 DNS record。
- Reverse DNS 和 IP check — 查看 IP 信息以及 PTR/reverse-DNS 数据。
- Domain info 和 domain age — 提供域名的基础信息。
- Port check — 测试目标端口从 probe 所在位置是否可达。
- Find your IP — 显示 service 看到的 public IP。
- Ping 和 traceroute — 提供 latency、packet loss 和到目标路径相关的 network signal。
- Hosting check 和 CMS detection — 提供可能有助于识别基础设施和技术栈的信号。
我会刻意把这些结果当作“信号”而不是“证明”。PTR record 不能证明 server 的所有者。根据公开 fingerprint 做出的 CMS detection 不能证明精确的软件栈。从一个 probe 无法访问某个端口，也可能只是路径上被过滤，并不意味着这个端口对所有地方都关闭。
我如何解读这些结果
真正的价值来自把多个检查放在一起看，而不是孤立地读取某一个结果。
例如，如果 DNS 返回预期地址、HTTPS 证书有效、网站从两个外部 VDS 都能正常响应，但我本地还是打不开，我会先深入检查本地路径，而不是马上修改 server。反过来，如果 DNS 结果不一致，或者 remote website check 也失败，就有更多理由优先检查 infrastructure。
Ping 和 traceroute 也需要谨慎。ICMP 可能被过滤或 rate-limit。Traceroute 中某个 hop 没有回应，不代表这个 node 一定坏了；不响应 ping 的 host 也完全可能正常提供 HTTPS。这些工具的价值在于增加上下文，而不是给出一个最终诊断。
我最看重的原则是：一次成功的检查不能证明整个系统健康，一次失败的检查也不能单独解释根因。
网站可用性和 SEO 不是一回事
可用性对 SEO 也重要，但技术宕机并不等于 ranking problem。Crawling 不等于 indexing，indexing 也不等于 traffic。
如果 crawler 因 DNS、网络或 server error 无法访问网站，那么在那个时间点，它就无法成功抓取受影响的内容。Google 的文档说明，crawling 过程中的 network error 和 DNS error 会以类似 server-side 5xx error 的方式处理，长时间不可用也可能影响 crawl 和已经 index 的 URL。但这不意味着每次短暂 outage 都会自动造成 SEO 损失，也不意味着一个诊断工具能够证明之后的 traffic 变化就是由这次 outage 导致的。
对用户来说逻辑更直接：如果访问不了，就无法使用网站。根据项目类型，这可能意味着丢失 session、lead、conversion 或 revenue。不过技术检查本身并不会计算这些 business impact。
遇到“网站挂了”时，我希望按这个顺序排查
- 先从另一个网络确认症状。 不要把本地浏览器的结果当成整个互联网的状态。
- 检查 DNS。 确认域名能解析，并返回预期 record。
- 检查 HTTPS/TLS。 查看证书有效性和连接错误。
- 检查所需端口。 至少确认从 probe 位置是否可达。
- 比较网络信号。 把 ping 和 traceroute 当作辅助证据，而不是单一 pass/fail 判断。
- 查看 IP、reverse DNS、hosting 和 CMS 信号。 它们可以帮助确认流量是否真的到达预期 infrastructure。
- 最后再缩小调查范围。 判断现有证据更偏向 application、server、DNS、network path 还是 local environment。
这不是适用于所有 incident 的标准 protocol。对我来说，它的意义是避免一个常见错误：只因为唯一的信息是“网站打不开”，就去修改错误的 layer。
先解决真实需求，再考虑变现
目前 Gitae 没有 monetization。我最初先为自己做它，因为我需要一种快速方式，从自己电脑之外检查网站，然后直接继续做 DNS、证书、端口和网络诊断，而不是在很多互不相关的工具之间来回切换。
现在的目标是让 diagnostics 更有用，并观察这个项目是否能通过 SEO 和真实需求获得 organic traffic。如果它哪怕只达到中等流量，我希望加入自动 website monitoring 和即时 messenger alert。这样同一个思路就会从手动诊断扩展到故障检测：先发现某项服务不可用，再尽快给 owner 足够的信息开始调查。
核心原则我希望一直保持简单
“Up”和“down”是症状，不是解释。
DNS、HTTPS/TLS、routing、port、hosting、application 以及用户自己的网络，都可能造成看起来很简单的 availability problem。Gitae 不会神奇地找出每一个 root cause，两个外部 server 也不可能代表整个互联网。但它可以把多个独立信号放在同一个地方。
这就是我真正想要的工具：帮助我从“网站打不开”走到一个更有用的问题：“下一步应该调查哪一层？”