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

建站入门教程 - 怎样检查访问状态与错误页

检查访问状态与错误页，核心是先用命令行或浏览器开发者工具拿到 HTTP 状态码，再结合响应头、页面内容和服务器日志判断问题出在哪一层。下面用一个假设例子说明完整流程：假设你刚给一个静态站点绑好域名，浏览器打开显示“无法访问此网站”，你需要逐步收集证据，而不是反复刷新。

先分清三类现象：连不上、连上但报错、连上但内容不对

这三类现象对应的排查方向不同，先归类能少走弯路。

• 连不上：浏览器提示 DNS 解析失败、连接超时、拒绝连接。此时还没进入 HTTP 层，问题多在域名解析、服务器是否运行、端口是否开放。
• 连上但报错：能看到服务器返回的 4xx 或 5xx 错误页。说明网络链路通了，问题在请求路径、权限或服务端程序。
• 连上但内容不对：状态码是 200，但页面是默认页、旧缓存或跳转到了别的地址。问题多在配置、缓存或重定向规则。

判断依据就是状态码本身。用 curl -I https://example.com 只看响应头，第一行形如 HTTP/1.1 200 OK，其中 200 是状态码。这个命令在 Windows、macOS、Linux 的终端都能用，前提是系统已安装 curl。

用 curl 分层检查的具体步骤

仍用上面的假设例子，按顺序执行，每一步都记录输出：

1. 先查域名解析：nslookup example.com 或 dig example.com。如果返回不到 IP，问题在 DNS，不用继续查服务器。
2. 再查端口连通：curl -v https://example.com，看是否卡在 Trying 1.2.3.4...。长时间无响应可能是防火墙或安全组未放行 443 端口。
3. 再看状态码：curl -I https://example.com。若返回 301/302，看 Location 头指向哪里；若返回 403、404、500，记录具体数字。
4. 最后看页面内容：curl https://example.com/some-page，对比返回的 HTML 是否为你预期的页面。

常见错误是只做第 3 步。状态码 200 并不代表内容正确，比如服务器返回了默认欢迎页，状态码同样是 200。所以第 4 步的内容核对不能省。

4xx 与 5xx 的区分和常见原因

状态码首位数代表错误归属，这是判断责任方的第一依据。

• 400：请求本身有问题，如 URL 含非法字符。检查你输入的地址和参数。
• 403：服务器理解了请求但拒绝执行。可能是目录权限、IP 限制或访问规则拦截。
• 404：请求的路径在服务器上不存在。检查文件是否上传到正确目录、大小写是否一致。
• 500：服务端程序执行出错。需要查看应用日志，而不是只改前端。
• 502 / 504：反向代理或网关拿不到后端响应。可能是后端进程崩溃或超时。

注意，4xx 通常说明请求方或配置有问题，5xx 通常说明服务端有问题，但这不是绝对规则。例如某些 CDN 或代理会用自己的错误页替换源站响应，此时状态码可能被改写，需要结合响应头里的 Server、Via 字段判断是谁返回的。

浏览器开发者工具能补充什么证据

命令行看不到的资源加载失败，可以在浏览器里查。按 F12 打开开发者工具，切到 Network 面板，刷新页面。这里能看到每个请求的状态码、耗时、响应头。

重点看两类：一是主文档请求的状态码，二是被标记为红色或 4xx/5xx 的子资源，比如 CSS、JS、图片。常见错误是主页面 200 但某个 JS 文件 404，导致页面功能异常却看不出明显报错。此时在 Network 面板按状态码排序，能快速定位。

如果状态码显示 (from disk cache) 或 (from memory cache)，说明看到的是缓存结果。勾选 Disable cache 后刷新，才能拿到真实响应。

把证据对应到可能原因

收集完状态码、响应头和日志后，做一次对应：

• DNS 无解析结果 → 检查域名解析记录是否生效、是否填错主机记录。
• 端口不通 → 检查服务器进程是否启动、防火墙与安全组规则。
• 403 → 检查文件与目录权限、访问控制配置。
• 404 → 检查文件路径、URL 重写规则、大小写。
• 500 → 查看应用错误日志，定位具体异常。
• 502/504 → 检查后端服务状态与代理超时设置。

需要强调：同一现象可能有多个解释。比如“无法访问”既可能是 DNS 没生效，也可能是服务器宕机，还可能是本地网络问题。不要看到一种现象就断定唯一原因，而应逐层排除。判断结果是否成立，取决于你是否有对应层的证据，而不是猜测。

下一步，选一个你正在排查的地址，按上面第 1 到第 4 步依次执行，把每步输出记下来，再对照可能原因表定位。这样得到的结论才有依据。