📍 WDQWDWQD987AAAAA:216.73.217.153
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ceef04c9e132.html
📄

自建博客步骤怎样检查访问状态：交付前把访问链路逐项验收

检查自建博客的访问状态，核心是确认三件事：服务器是否正常响应、域名是否正确解析到这台服务器、页面返回的是不是预期内容。多人协作时不要只问一句“能打开吗”，而要把这三项拆成可记录、可复现的检查项，谁执行、结果是什么、异常出在哪一步，都写清楚，才能减少返工。

从一个假设的协作场景说起

假设你和两位同伴一起搭建博客：A 负责买服务器和部署程序，B 负责域名解析，C 负责写文章并做最终验收。A 说“已经部署好了”，B 说“域名也解析了”，C 打开浏览器却发现页面报错。此时如果三人只凭“能不能打开”沟通，就会互相推责。正确做法是让 C 按顺序执行下面的检查，并把每一步的结果截图或记下文字，交回给对应的人。

第一步：先确认服务器本身能响应

绕过域名，直接用服务器 IP 访问，能判断问题出在服务器还是域名。

1. 拿到服务器的公网 IP，在浏览器地址栏输入 http://服务器IP，观察是否返回博客页面或服务器默认页。
2. 如果打不开，在本地终端执行 ping 服务器IP，看是否有回应；再用 curl -I http://服务器IP 查看返回的 HTTP 状态码。
3. 结果判断：能返回 200，说明 Web 服务在运行；返回 403、404，说明服务在跑但路径或权限有问题；完全无响应，可能是防火墙未放行、服务未启动或 IP 填错。

常见错误是跳过这一步直接查域名，把服务器故障误判成解析故障，白白折腾 DNS。适用条件是你能直接拿到服务器 IP，并且本地网络没有限制访问该端口。

第二步：确认域名解析指向正确

域名解析错了，浏览器就找不到你的服务器。检查方法是查询域名当前解析到的 IP，再和服务器实际 IP 对比。

• 在终端执行 nslookup 你的域名 或 dig 你的域名，记录返回的 IP。
• 把这个 IP 与第一步用的服务器 IP 对照。不一致，说明解析记录没生效、填错，或域名还没完成实名与备案类前置流程。
• 刚改过解析时，不同网络环境看到的旧记录可能不同，可以换一个网络或用公共 DNS 再查一次，但不要据此断定“已经生效”。

这一步的判断结果很明确：IP 一致且服务器能响应，问题基本不在解析；IP 不一致，先解决解析再谈页面。多人协作时，把查询命令和返回结果贴进交付记录，比口头说“解析好了”可靠得多。

第三步：检查页面返回内容与状态码

域名和服务器都通了，还要确认返回的是不是你要交付的那个页面，而不是默认页、错误页或缓存旧页。

1. 用 curl -I https://你的域名 看状态码和响应头。200 表示正常返回；301、302 表示跳转，要确认跳转目标是否是最终地址；5xx 表示服务器端出错。
2. 打开页面后核对标题、首页文章列表、导航链接是否与预期一致。如果显示的是服务器默认欢迎页，说明站点根目录或反向代理配置没指对。
3. 逐一点开文章页、分类页、关于页，确认没有 404。站内链接失效往往在首页看不出来，却会在交付后被读者发现。
4. 用手机网络再访问一次，排除只在本地 hosts 文件或内网 DNS 下才能打开的情况。

如果启用了 HTTPS，还要看证书是否匹配当前域名、是否已过期。浏览器提示证书错误，说明证书配置或续期环节需要处理，这不属于解析问题。

把检查结果写成可交付的记录

多人协作减少返工的关键，是让每个异常都有明确的归属。可以按下面的格式留一条记录，假设的例子如下：

• 服务器 IP 访问：返回 200，正常。
• 域名解析查询：返回 IP 与服务器一致。
• 首页访问：返回 200，内容正确。
• 文章页访问：其中一个返回 404，链接写错，需内容负责人修正。

这样交付时，谁负责哪一项、哪一项还没通过一目了然。需要提醒的是，访问状态正常不等于被搜索引擎收录或排名靠前，这两件事要分开看待；一次配置改动前后的表现也可能受搜索需求变化和数据采集差异影响，不能只凭某一天的截图下结论。

下一步建议：把上面三步整理成一张固定检查清单，放进你们的协作文档，每次部署或改解析后由验收人逐项填写结果，再决定是否可以对外交付。