排查网页打不开问题

Question

第一步

1、通过终端 ping 网页域名，是否能通，如果不通，检查域名地址是否正确，否则检查 DNS

第二步

2、浏览器打开开发者模式，查看网页返回的 http 状态码，根据不同的 HTTP 状态进行排查

HTTP 状态码是服务器用来响应客户端请求的标准数字代码。不同的状态码表示不同的情况，可以大致分为五个类别：

1xx - 信息性状态码 (Informational) ：表示接收的请求正在处理。

这类状态码通常是正常的，不需要特别的排查。

• 100 Continue (继续)
• 101 Switching Protocols (切换协议)

2xx - 成功状态码 (Successful) ：表示请求已成功被服务器接收、理解、并接受。

成功状态码通常意味着请求已成功处理。不需要特别排查。

• 200 OK (成功)
• 201 Created (已创建)
• 202 Accepted (已接受)
• 204 No Content (无内容)

3xx - 重定向状态码 (Redirection) ：表示需要进一步操作以完成请求。

• 301 Moved Permanently (永久移动) 检查服务器端的重定向设置。如果是意料之外的重定向，确认服务器配置或代码中的重定向逻辑。
• 302 Found (找到) 检查服务器端的重定向设置。如果是意料之外的重定向，确认服务器配置或代码中的重定向逻辑。
• 303 See Other (查看其他位置)
• 304 Not Modified (未修改) 这通常是正常的，表示资源自上次请求以来未修改。检查缓存设置。
• 307 Temporary Redirect (临时重定向)
• 308 Permanent Redirect (永久重定向)

4xx - 客户端错误状态码 (Client Error) ：表示请求包含语法错误或无法完成。

• 400 Bad Request (错误请求) 检查请求是否正确。通常是请求格式错误。
• 401 Unauthorized (未授权) 检查认证信息是否正确。
• 403 Forbidden (禁止) 确认服务器端权限设置。
• 404 Not Found (未找到) 检查请求的资源是否存在。
• 405 Method Not Allowed (方法不允许) 确认是否使用了服务器不支持的 HTTP 方法。
• 408 Request Timeout (请求超时) 检查网络问题或服务器性能问题。
• 429 Too Many Requests (请求过多) 检查是否触发了服务器的限流措施，如有需要调整请求频率。

5xx - 服务器错误状态码 (Server Error) ：表示服务器在处理请求的时候发生了错误。

• 500 Internal Server Error (服务器内部错误) 检查服务器日志，确认代码、数据库、或配置中的问题。
• 501 Not Implemented (未实现) 服务器不支持请求的功能。
• 502 Bad Gateway (错误网关) 检查服务器与上游服务器的连接。
• 503 Service Unavailable (服务不可用) 服务器可能超载或进行维护。检查服务器性能和配置。
• 504 Gateway Timeout (网关超时) 类似于 502，检查服务器与上游服务器的连接问题。

这些状态码是 Web 开发和网络诊断中的重要部分。

第三步

3,检查网页服务器状态，例如 Nginx，Apache 等

例如检查 Nginx 服务器是否正常运行，可以通过以下步骤进行：

检查 Nginx 服务状态 ：

在命令行输入 `sudo systemctl status nginx` 或 `service nginx status`
（取决于你的操作系统和服务管理器）。这会显示 Nginx 的运行状态。

检查端口监听 ：

使用 `netstat -tulpn | grep nginx` 或 `ss -tulpn | grep nginx` 
来确认 Nginx 是否正在监听正确的端口（通常是 80 和 443 端口）。

访问网站 ：

尝试在 nginx 服务器中输入你的服务器 IP 或绑定的域名，看是否能成功加载网页。
或者在 nginx 服务器上 curl 命令访问 127.0.0.1+端口，看是否能成功加载网页

查看 Nginx 错误日志 ：

Nginx 的错误日志通常位于 `/var/log/nginx/error.log`。
查看该文件可能会给出一些为什么 Nginx 无法正常运行的线索。

检查 Nginx 配置文件 ：

使用 `nginx -t` 命令来测试 Nginx 配置文件是否有语法错误。

或者使用 ps auxww | grep [进程号] 查看 Nginx 启动命令是否指定了配置文件

检查系统资源 ：

使用 `top` 或 `htop` 等命令来检查服务器的
CPU 和内存使用情况，确保系统资源没有被耗尽。

一样的道理可以检查 Apache。

第四步

4,检查开发环境状态，例如 Java，Python，PHP 等

例如检查 Java：jstat -gc [pid] 命令提供了 Java 堆内存中对象的垃圾收集和堆使用情况的信息。输出的每列数据代表不同的内存区域或统计信息。以下是典型输出的列和它们的含义：

1. S0C: Survivor space 0 capacity (KB) - 幸存区 0 的容量。
2. S1C: Survivor space 1 capacity (KB) - 幸存区 1 的容量。
3. S0U: Survivor space 0 utilization (KB) - 幸存区 0 的使用量。
4. S1U: Survivor space 1 utilization (KB) - 幸存区 1 的使用量。
5. EC: Eden space capacity (KB) - 伊甸园区的容量。
6. EU: Eden space utilization (KB) - 伊甸园区的使用量。
7. OC: Old space capacity (KB) - 老年代区的容量。
8. OU: Old space utilization (KB) - 老年代区的使用量。
9. MC: Metaspace capacity (KB) - 元空间的容量。
10. MU: Metaspace utilization (KB) - 元空间的使用量。
11. CCSC: Compressed Class Space Capacity (KB) - 压缩类空间的容量。
12. CCSU: Compressed Class Space Used (KB) - 压缩类空间的使用量。
13. YGC: Number of young generation GC events - 年轻代垃圾收集发生的次数。
14. YGCT: Young generation garbage collection time - 年轻代垃圾收集所用的时间。
15. FGC: Number of full GC events - 完全垃圾收集发生的次数。
16. FGCT: Full garbage collection time - 完全垃圾收集所用的时间。
17. GCT: Total garbage collection time - 垃圾收集所用的总时间。

通过分析这些数据，你可以获得 JVM 堆内存使用情况和垃圾收集活动的详细视图。这对于性能调优和诊断内存问题是非常有帮助的。

有一些通用的指标可以指示潜在的问题：

• 频繁的年轻代垃圾收集 (YGC) ：如果 YGC 数值不断快速增加，可能表明年轻代空间太小或者程序在短时间内生成了大量的临时对象。
• 长时间的年轻代垃圾收集 (YGCT) ：如果单次 YGCT 值较高，说明年轻代垃圾收集花费了太多时间，可能是由于堆大小不足或垃圾收集器设置不合理。
• 频繁的完全垃圾收集 (FGC) ：FGC 频繁增加可能表明老年代或永久代/元空间（取决于 Java 版本）容量不足，或者有大量对象长期存活。
• 长时间的完全垃圾收集 (FGCT) ：高 FGCT 值表示完全垃圾收集占用了太多时间，可能是由于老年代空间太小、存在大量长生命周期的对象，或垃圾收集器设置不当。
• 高老年代使用量 (OU) ：如果 OU 值持续接近 OC 值，表明老年代空间接近满载，可能导致频繁的完全垃圾收集。
• 高元空间使用量 (MU) ：MU 接近 MC 表明元空间使用量高，可能由于加载了大量类或内存泄漏。
• 总垃圾收集时间 (GCT) ：如果 GCT 相对于应用运行时间过高，表明应用花费了大量时间在垃圾收集上。

识别这些异常情况后，可能需要对 JVM 的堆大小、垃圾收集器类型、垃圾收集策略等进行调整，或者检查应用代码以查找内存泄漏或不必要的对象创建。对于具体的调优策略，需要根据应用程序的具体情况和需求来定。

jstat -gcutil <pid> <interval> <count> 命令用于显示目标 Java 进程的垃圾收集（GC）统计信息，并按照设定的时间间隔重复显示指定次数。下面是该命令各部分的解释：

1. jstat ：Java 的统计监控工具。
2. -gcutil ：这是 jstat 的一个选项，用于显示目标 Java 进程的垃圾收集统计信息，包括堆区域的使用百分比等。
3. <pid> ：目标 Java 进程的进程 ID。您需要替换为您想监控的 Java 进程的实际进程 ID。
4. <interval> ：显示信息的时间间隔，单位为毫秒。这个参数是可选的，默认情况下只显示一次数据。
5. <count> ：该命令要重复执行的次数。这个参数也是可选的，如果未指定， jstat 将持续显示数据，直到被中断。

例如，如果您想查看进程 ID 为 1234 的 Java 进程的垃圾收集统计信息，每隔 5000 毫秒（即 5 秒）更新一次，总共更新 10 次，您可以使用以下命令：

jstat -gcutil 1234 5000 10

这个命令将每 5 秒显示一次进程 ID 为 1234 的 Java 进程的垃圾收集统计信息，共显示 10 次。

jstat -gcutil 1234 5000 10 这个命令的输出将展示进程 ID 为 1234 的 Java 应用的垃圾收集（GC）相关的信息，每 5 秒刷新一次，共刷新 10 次。每次刷新将展示类似以下的数据（具体数值会根据应用状态有所不同）：

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00  76.85  40.07  97.69  95.83   118    1.472    2      0.234    1.706
  0.00   0.00  80.37  41.07  97.69  95.83   118    1.472    2      0.234    1.706
  ...

这里是各列数据的意义：

• S0 和 S1 ：幸存区（Survivor spaces）0 和 1 的使用百分比。
• E ：伊甸园区（Eden space）的使用百分比。
• O ：老年代（Old generation）的使用百分比。
• M ：元数据区（Metaspace）的使用百分比。
• CCS ：压缩类空间（Compressed Class Space）的使用百分比。
• YGC ：年轻代垃圾收集（Young Generation Garbage Collection）发生的次数。
• YGCT ：年轻代垃圾收集所花费的时间（秒）。
• FGC ：完全垃圾收集（Full Garbage Collection）发生的次数。
• FGCT ：完全垃圾收集所花费的时间（秒）。
• GCT ：总垃圾收集时间（秒）。

这些数据对于理解和调优 Java 应用的内存和垃圾收集行为非常有帮助。

如果 Java 应用出现异常， jstat -gcutil 命令输出的数据可能会展示一些异常模式，比如：

频繁的年轻代垃圾收集（YGC） :

• 说明：如果 YGC 发生的频率非常高，可能意味着伊甸园区（Eden space）太小或者应用产生了大量的短生命周期对象。
• 举例：如果每几秒钟就有一次 YGC，且 YGCT（年轻代垃圾收集时间）相对较高，可能说明存在问题。

老年代（Old Generation）使用率持续增高 :

• 说明：如果老年代的使用率不断攀升且不下降，可能表明内存泄漏或老年代大小不足。
• 举例：如果老年代的使用率（O 列）逐渐接近 100%且不见下降，可能是内存泄漏的迹象。

频繁的完全垃圾收集（FGC） :

• 说明：频繁的 FGC 可能会导致系统停顿，影响性能。可能是由于老年代空间不足或内存泄漏造成的。
• 举例：如果 FGC 的次数（FGC 列）在短时间内迅速增加，且 FGCT（完全垃圾收集时间）也在增加，可能会出现性能问题。

垃圾收集时间过长 :

• 说明：如果垃圾收集所需的时间过长，可能会导致应用响应缓慢或停顿。
• 举例：如果 YGCT 或 FGCT 的值异常高，意味着垃圾收集占用了大量时间，可能导致应用性能下降。

总之，通过监控 jstat -gcutil 命令的输出，可以识别出潜在的内存管理问题，如内存泄漏、不恰当的垃圾收集策略或内存分配不足等。然后可以根据这些信息进行调优或进一步调查。

第五步

5,检查操作系统

检查防火墙设置 ：

• 确保防火墙没有阻止 Nginx 使用的端口，特别是 HTTP (80) 和 HTTPS (443) 端口。
  s
  2. 检查 SELinux 状态 （如果适用）：
• 在某些 Linux 发行版上，SELinux 可能会限制 Nginx 的操作。可以通过 getenforce 查看其状态，并根据需要进行调整。

检查 Nginx 的访问日志 ：

• 访问日志通常位于 /var/log/nginx/access.log 。它可以提供访问者请求的详细信息，有助于识别潜在问题。

查看系统日志 ：

• 有时系统日志（如 /var/log/syslog 或 /var/log/messages ）也能提供服务器问题的线索。

后面遇到具体场景再具体补充