Web开发避坑指南：默语为你详解502/503/504/400/401及Connection Reset（小白自救手册）

摘要： 嘿，各位奋战在Web开发一线的小伙伴们，我是默语！在我们的日常工作中，与HTTP错误码打交道是家常便饭。502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout、400 Bad Request、401 Unauthorized，还有那句令人闻风丧胆的“Connection reset by peer”……这些是不是听起来就很熟悉，甚至有点“亲切”？本文将化身你的“错误码翻译官”和“问题定位导航员”，用小白也能看懂的语言，结合生动的场景比喻和实际排查步骤，带你深入理解这些常见Web错误的含义、原因及解决方法，让你在遇到它们时不再手足无措，能够从容应对，快速定位并解决问题！

博主 默语带您 Go to New World.
✍ 个人主页—— 默语 的博客👦🏻 优秀内容
《java 面试题大全》
《java 专栏》
《idea技术专区》
《spring boot 技术专区》
《MyBatis从入门到精通》
《23种设计模式》
《经典算法学习》
《spring 学习》
《MYSQL从入门到精通》数据库是开发者必会基础之一~
🍩惟余辈才疏学浅，临摹之作或有不妥之处，还请读者海涵指正。☕🍭
🪁 吾期望此文有资助于尔，即使粗浅难及深广，亦备添少许微薄之助。苟未尽善尽美，敬请批评指正，以资改进。！💻⌨

---

默语是谁？

大家好，我是 默语，别名默语博主，擅长的技术领域包括Java、运维和人工智能。我的技术背景扎实，涵盖了从后端开发到前端框架的各个方面，特别是在Java 性能优化、多线程编程、算法优化等领域有深厚造诣。

目前，我活跃在CSDN、掘金、阿里云和 51CTO等平台，全网拥有超过15万的粉丝，总阅读量超过1400 万。统一 IP 名称为 默语 或者 默语博主。我是 CSDN 博客专家、阿里云专家博主和掘金博客专家，曾获博客专家、优秀社区主理人等多项荣誉，并在 2023 年度博客之星评选中名列前 50。我还是 Java 高级工程师、自媒体博主，北京城市开发者社区的主理人，拥有丰富的项目开发经验和产品设计能力。希望通过我的分享，帮助大家更好地了解和使用各类技术产品，在不断的学习过程中，可以帮助到更多的人，结交更多的朋友.

---

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

默语：您的前沿技术领航员

👋 大家好，我是默语！
📱 全网搜索“默语”，即可纵览我在各大平台的知识足迹。

📣 公众号“默语摸鱼”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

💬 微信端添加好友“Solitudemind”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 1 月 2 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

---

文章目录

• 默语：您的前沿技术领航员
• • @[TOC]
• Web开发避坑指南：默语为你详解502/503/504/400/401及Connection Reset（小白自救手册）
• • 引言：
  • 正文
  • • 一、502 Bad Gateway：网关的“坏消息”
    • • 1.1 它是什么？
      • 1.2 小白场景比喻
      • 1.3 常见原因
      • 1.4 如何排查和解决？（开发者/运维视角）
      • 1.5 “代码”示例 (Nginx配置相关)
    • 二、503 Service Unavailable：服务暂不可用
    • • 2.1 它是什么？
      • 2.2 小白场景比喻
      • 2.3 常见原因
      • 2.4 如何排查和解决？
    • 三、“Connection reset by peer”：连接被无情重置
    • • 3.1 它是什么？
      • 3.2 小白场景比喻
      • 3.3 常见原因
      • 3.4 如何排查和解决？
    • 四、504 Gateway Timeout：网关等到花儿都谢了
    • • 4.1 它是什么？
      • 4.2 小白场景比喻
      • 4.3 常见原因
      • 4.4 如何排查和解决？
    • 五、400 Bad Request：请求“格式不对”
    • • 5.1 它是什么？
      • 5.2 小白场景比喻
      • 5.3 常见原因 (主要由客户端引起)
      • 5.4 如何排查和解决？
    • 六、401 Unauthorized：未授权，请先“亮身份”
    • • 6.1 它是什么？
      • 6.2 小白场景比喻
      • 6.3 常见原因
      • 6.4 如何排查和解决？
  • 总结：从容面对Web世界的“小意外”

今天我们来聊聊Web开发中那些让人头疼，但又不得不面对的“老朋友们”——各种HTTP错误码。特别是对于刚入门的小白同学，看到这些错误码，可能瞬间就“懵圈”了。别怕！这篇博客就是你的“避坑指南”和“自救手册”，我会用最通俗易懂的方式，带你逐一认识这些常见错误，分析可能的原因，并给出排查和解决方案的思路。

---

Web开发避坑指南：默语为你详解502/503/504/400/401及Connection Reset（小白自救手册）

引言：

Web应用的世界就像一个庞大而精密的机器网络，浏览器（客户端）和服务器之间通过HTTP协议进行着无数次的请求和响应。然而，这个过程中并非总是一帆风顺。网络抖动、服务器过载、应用BUG、配置错误等都可能导致各种问题的出现，并通过HTTP状态码的形式反馈给我们。

对于开发者（尤其是后端开发者和运维同学）而言，能够快速准确地理解这些错误码背后的含义，是排查线上问题、保障服务稳定性的核心技能。对于前端开发者，了解这些错误也能帮助你更好地与后端协作，或者给用户更友好的提示。

这篇博客，默语将挑选几个最“臭名昭著”也最常见的HTTP错误码和网络问题进行“庖丁解牛”，目标是让你不仅知其然，更知其所以然，以后遇到它们，一眼就能看出“病灶”在哪！

正文

我们一个一个来“会诊”这些“疑难杂症”。

一、502 Bad Gateway：网关的“坏消息”

1.1 它是什么？

502 Bad Gateway错误表示作为网关或代理的服务器，从上游服务器（比如我们的应用服务器）收到了一个无效的响应。

1.2 小白场景比喻

想象你去一家餐厅（代理服务器/网关，如Nginx、Apache反向代理），点了一份宫保鸡丁。服务员（代理）去后厨（上游应用服务器）下单，结果后厨告诉服务员“我们今天没有鸡肉了，给你块豆腐吧”（一个不符合预期的、错误的响应），或者后厨直接“炸了”（应用服务器崩溃）。服务员很无奈，只能回来告诉你：“抱歉，厨房那边出了点问题，您的菜做不了了。” 这个“厨房出问题”的消息，就是502。

1.3 常见原因

• 上游应用服务器故障： 这是最常见的原因。你的应用服务器（如Tomcat, Node.js, Python Flask/Django应用）可能崩溃了、重启了、或者因为BUG返回了不正常的响应。

• 网络问题： 网关/代理服务器与上游应用服务器之间的网络连接存在问题（例如，防火墙阻止了连接、DNS解析错误、网络抖动丢包）。

• PHP-FPM等进程管理器问题： 如果你使用PHP，PHP-FPM进程可能挂了，或者配置有问题，导致Nginx无法从PHP-FPM获取到正确的响应。

• 负载均衡器配置错误： 如果使用了负载均衡器，它可能错误地将请求转发到了一个不健康或不存在的上游服务器。

• 代理服务器配置错误：

  Nginx或Apache等代理服务器自身的配置（如 proxy_pass指令）可能不正确。

• 资源耗尽： 上游服务器可能因为CPU、内存、连接数等资源耗尽而无法正常响应。

1.4 如何排查和解决？（开发者/运维视角）

1. 检查上游应用服务器状态：

   • 应用服务器是否在运行？尝试重启它。
   • 查看应用服务器的日志！这是定位问题的金钥匙。日志中通常会记录应用崩溃的原因或处理请求时的错误信息。

2. 检查网关/代理服务器日志：

   • Nginx日志通常在 /var/log/nginx/error.log 或 /var/log/nginx/access.log 。

   • Apache日志根据配置，可能在 /var/log/httpd/ 或 /var/log/apache2/ 目录下。

     • 日志中会记录向上游服务器请求失败的具体信息。

3. 网络连通性测试：

   • 在网关/代理服务器上，尝试 ping或 curl 你的上游应用服务器的IP和端口，看是否能通。

   • 检查防火墙规则（如iptables, firewalld, ufw）是否允许了网关到上游服务器的访问。

   • 检查DNS解析是否正确。

4. 检查PHP-FPM状态（如适用）：

systemctl status php-fpm (或对应你的PHP版本，如 php7.4-fpm)

• 查看PHP-FPM的错误日志。

5. 资源监控：

   • 使用
     top, htop, free -m, df -h等命令检查上游服务器的CPU、内存、磁盘使用情况。

6. 临时增加代理超时（谨慎）： 有时上游处理慢也可能被误判，但502更多是连接或响应格式问题。

1.5 “代码”示例 (Nginx配置相关)

一个可能导致502的Nginx配置片段（如果http://backend_server_address无法访问或返回错误）：

Nginx

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://backend_server_address; # 如果这里出问题
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

你需要确保 backend_server_address (例如 http://127.0.0.1:8080 或 http://app-server-ip:port) 是可访问且能正常工作的。

二、503 Service Unavailable：服务暂不可用

2.1 它是什么？

503 Service Unavailable错误表示服务器当前无法处理请求。这通常是临时性的，服务器预计在稍后会恢复正常。

2.2 小白场景比喻

你还是去那家餐厅（服务器）。

• 情况一：门口挂了个牌子“今日大扫除，暂停营业半天”。
• 情况二：餐厅爆满，服务员告诉你“客官实在抱歉，现在太忙了，您稍等会儿再来行吗？” 这两种情况，都是503。服务器告诉你：“我现在忙不过来”或“我正在维护，请稍后再试”。

2.3 常见原因

• 服务器过载： 请求量过大，超出了服务器的处理能力上限（CPU、内存、网络带宽、数据库连接池耗尽等）。
• 服务器维护： 服务器正在进行计划内维护，例如部署新版本、打补丁、重启服务等。
• 应用启动中： 应用服务器（如Tomcat）正在启动过程中，尚未准备好处理请求。
• 依赖服务不可用： 应用依赖的后端服务（如数据库、缓存、第三方API）出现故障，导致自身无法提供服务。
• 资源限制： 操作系统级别的资源限制，如最大打开文件数、最大进程数等。
• DDoS攻击： 大量恶意请求耗尽服务器资源。

2.4 如何排查和解决？

1. 判断是临时性过载还是持续性问题：

   • 如果是突发流量，考虑扩容（增加服务器实例、提升配置）或限流策略。
   • 如果是持续高负载，需要分析性能瓶颈并优化。

2. 检查服务器资源使用情况：
   top, htop (CPU, 内存), vmstat (虚拟内存), iostat (磁盘I/O), netstat(网络连接)。

3. 查看应用服务器日志和系统日志：

   • 应用日志可能会有资源不足、连接池耗尽、依赖服务调用失败等错误。

   • 系统日志（如 /var/log/messages或 journalctl）可能会有OOM (Out Of Memory) killer的记录

4. 确认是否有维护或部署操作： 和运维团队沟通。

5. 检查依赖服务： 确保数据库、缓存服务等都正常运行。

6. 合理设置Retry-After响应头：

   如果可以预估恢复时间，在503响应中带上Retry-After 头，告诉客户端何时可以重试。

   HTTP/1.1 503 Service Unavailable
   Content-Type: application/json
   Retry-After: 300  // 表示5分钟 (300秒) 后重试
   
   {"error": "Service temporarily unavailable due to maintenance."}
   

三、“Connection reset by peer”：连接被无情重置

3.1 它是什么？

这严格来说不是一个HTTP状态码，而是一个网络层面的错误。它表示TCP连接在数据传输过程中被对端（peer，通常是服务器）强行关闭了。

3.2 小白场景比喻

你正在和朋友打电话聊得正嗨（TCP连接建立，数据传输中），对方那边突然“咔嚓”一声挂断了电话（连接被重置），你这边就会听到“嘟嘟嘟”的忙音。

3.3 常见原因

• 服务器端应用进程崩溃： 处理请求的应用进程（如Java线程、Python worker）意外终止。

• 防火墙或网络设备： 中间的防火墙、负载均衡器或某些网络安全设备可能因为超时、策略、或检测到异常流量而主动切断了连接。

• 服务器主动关闭连接：

  • 服务器处理请求时间过长，超过了自身的超时设置（如Keep-Alive超时），主动关闭了空闲连接。
  • 服务器检测到客户端行为异常（如发送了过多数据）。

• 操作系统层面：

  服务器的TCP栈因为某些原因（如积压了太多未完成的连接 ESTABLISHED 但长时间无数据，或 FIN_WAIT_2 状态的连接过多）而重置连接。

• 负载均衡器的健康检查失败： 如果后端服务器未能通过负载均衡器的健康检查，负载均衡器可能会重置已建立到该服务器的连接。

3.4 如何排查和解决？

这是一个比较棘手的错误，因为它可能发生在多个层面。

1. 检查服务器端应用日志： 这是首要步骤！查找在连接重置发生时间点附近是否有应用崩溃、异常退出、或处理超时的记录。

2. 检查服务器系统日志： 查看是否有内核错误、OOM killer等信息。

3. 检查防火墙和网络设备日志： 如果有权限，检查中间网络设备的日志，看是否有相关的连接重置记录。

4. 网络抓包分析：

   在客户端和服务器端（或关键网络节点）同时使用 tcpdump 或 Wireshark 抓包，分析TCP交互过程，看是谁发起了RST包。这对小白来说可能较难，但这是最根本的分析手段。

   # 在服务器端抓包示例 (替换eth0为你的网卡, port 80为例)
   sudo tcpdump -i eth0 -w connection_reset.pcap port 80
   

5. 检查Keep-Alive设置： 客户端和服务器的Keep-Alive超时设置是否匹配？如果服务器端超时设置过短，而客户端还在使用这个连接，就可能被重置。

6. 代码层面： 客户端代码是否正确处理了连接的生命周期？是否有可能在连接已关闭后仍尝试写入数据？服务端代码是否有未捕获的异常导致进程退出？

7. 资源限制： 检查服务器是否有足够的套接字资源、文件描述符等。

四、504 Gateway Timeout：网关等到花儿都谢了

4.1 它是什么？

504 Gateway Timeout错误表示作为网关或代理的服务器，在尝试从上游服务器获取响应时，没有在规定的时间内收到响应。

4.2 小白场景比喻

你还是去那家餐厅（代理服务器/网关），服务员（代理）去后厨（上游应用服务器）下单。这次后厨没说做不了，也没说太忙，而是让你“等着”。你等啊等，等了半小时（代理的超时时间），菜还没上来，服务员只好抱歉地告诉你：“对不起，厨房动作太慢了，我们等不起了。”

4.3 常见原因

• 上游应用服务器处理请求过慢：

  这是最主要的原因。

  • 复杂的数据库查询，尤其是慢SQL。
  • 大量的计算或I/O密集型操作。
  • 调用外部API耗时过长。
  • 应用代码存在性能瓶颈或死循环。

• 网络延迟： 网关/代理服务器与上游应用服务器之间的网络连接虽然通畅，但延迟很高。

• 代理服务器超时设置过短：

  网关/代理服务器（如Nginx）配置的超时时间（如 proxy_read_timeout）小于上游应用实际处理请求所需的时间。

• 上游服务器资源不足导致响应缓慢： 虽然没到503的程度，但CPU、内存紧张也会导致处理变慢。

4.4 如何排查和解决？

1. 优化上游应用服务器性能：

   • 代码层面： 分析和优化慢接口、耗时操作。使用性能分析工具（Profiler）定位瓶颈。
   • 数据库层面： 优化慢查询（加索引、改写SQL、分库分表等）。
   • 外部调用： 评估外部API的响应时间，考虑设置更短的调用超时或异步处理。

2. 增加代理服务器的超时时间（谨慎操作）：

   • Nginx示例：

     location /some_slow_api/ {
         proxy_pass http://backend_server_address;
         proxy_connect_timeout 10s; # 连接上游超时
         proxy_send_timeout 60s;    # 发送请求到上游超时
         proxy_read_timeout 120s;   # 从上游读取响应超时，这个最关键
         # ...其他配置...
     }
     

   • 默语提醒： 无脑增加超时时间治标不本，可能会掩盖后端性能问题，并可能耗尽代理服务器的连接资源。优先优化后端！

3. 检查网络质量：

   使用 ping, traceroute(或 mtr) 测试网关到上游服务器的网络延迟和丢包情况。

4. 异步处理耗时任务： 对于那些本身就需要很长时间处理的请求（如报表生成、批量数据处理），应考虑将其改造为异步任务，客户端轮询结果或通过回调通知。

五、400 Bad Request：请求“格式不对”

5.1 它是什么？

400 Bad Request错误表示服务器无法理解客户端发送的请求，因为请求的语法格式有错误。这是客户端的错误。

5.2 小白场景比喻

你去邮局寄信（发送HTTP请求）。

• 情况一：信封上地址写得乱七八糟，邮递员看不懂（请求语法错误）。
• 情况二：你说要寄一个“五彩斑斓的黑”的包裹，邮递员表示无法理解这种物品（请求参数不合法或语义错误）。 邮局会把信退给你，告诉你“您的请求有问题，我们处理不了”。

5.3 常见原因 (主要由客户端引起)

• 请求URL格式错误： 例如，URL中包含非法字符。

• 请求头不规范：

  例如，Content-Type 与实际发送的请求体格式不符。

• 请求体格式错误： 例如，期望收到JSON，但发送的JSON格式损坏（括号不匹配、引号问题等）；或者发送了表单数据但编码不正确。

• 参数无效或缺失： 请求中传递的参数不符合服务器端的校验规则（类型不对、长度超限、值不在允许范围内、必填参数未传）。

• 请求过大： 请求头或请求体的大小超过了服务器配置的限制。

• Cookie过大或无效。

5.4 如何排查和解决？

1. 客户端开发者自查：

   • 仔细检查请求的URL、请求头、请求体（特别是JSON或XML格式）。

   • 使用工具（如Postman、Insomnia、浏览器开发者工具的网络(Network)面板、curl命令）重新构造和发送请求，逐步排查是哪个部分出了问题。

   • curl 示例 (发送一个格式错误的JSON):

    # 错误的JSON: age应该是数字，但用了字符串；缺少逗号
    curl -X POST -H "Content-Type: application/json" \
         -d '{"name": "默语" "age": "三十"}' \
         http://your-api-endpoint/users
    # 期望服务器返回400
    
    # 正确的JSON示例:
    curl -X POST -H "Content-Type: application/json" \
         -d '{"name": "默语", "age": 30}' \
         http://your-api-endpoint/users
   

2. 服务器端开发者：

   • 查看服务器日志： 详细的服务器日志通常会指出请求的哪个部分不符合规范。

   • 加强输入校验：

     在服务器端对所有客户端输入进行严格的校验（格式、类型、范围、长度等），并对校验失败的请求返回明确的400错误和具体的错误信息，方便客户端调试。

     // 伪代码 (Java Spring Boot示例)
     // @PostMapping("/users")
     // public ResponseEntity<Object> createUser(@Valid @RequestBody UserDto userDto, BindingResult errors) {
     //     if (errors.hasErrors()) {
     //         Map<String, String> errorDetails = errors.getFieldErrors().stream()
     //             .collect(Collectors.toMap(FieldError::getField, FieldError::getDefaultMessage));
     //         return ResponseEntity.badRequest().body(errorDetails); // 返回400和详细错误
     //     }
     //     // ... 创建用户逻辑 ...
     //     return ResponseEntity.status(HttpStatus.CREATED).body(userService.createUser(userDto));
     // }
   

   • 明确API文档： 提供清晰、准确的API文档，说明请求格式、参数要求等。

六、401 Unauthorized：未授权，请先“亮身份”

6.1 它是什么？

401 Unauthorized错误表示客户端请求的资源需要身份认证，但客户端未能提供有效的认证信息，或者提供的认证信息不正确/已过期。

6.2 小白场景比喻

你想进入一个会员制的私人俱乐部（需要认证的资源）。

• 情况一：你没带会员卡就想进（未提供认证信息）。

• 情况二：你出示了一张过期的会员卡，或者一张假的会员卡（认证信息无效）。 保安会拦住你：“对不起，先生/女士，您没有权限进入。”并可能告诉你需要什么样的凭证（通过 WWW-Authenticate响应头）。

6.3 常见原因

• 未提供认证凭据：客户端没有在请求中（通常是 Authorization请求头）包含任何认证信息。

• 认证凭据无效：

  • 提供的用户名/密码错误。
  • 提供的API Token、JWT (JSON Web Token)、OAuth令牌等无效、已过期、或被吊销。
  • 认证方案不匹配（例如，服务器期望Bearer Token，客户端发送了Basic Auth）。

• 认证信息格式错误：
  Authorization 头的格式不符合服务器期望的规范（如Basic Auth的username:password 未正确Base64编码，或Bearer Token前缀Bearer 缺失）。

6.4 如何排查和解决？

1. 客户端开发者自查：

   • 是否发送了认证信息？

     检查请求头中是否有 Authorization头，并且其值是否按API文档要求正确设置。

   • 认证信息是否正确且有效？

     • 确认用户名/密码拼写无误。
     • 确认Token是否在有效期内，是否是从正确的途径获取的。
     • 确认Token是否有访问该特定资源的权限（Scope）。

   • 认证方案是否正确？ API是要求Basic Auth, Bearer Token, Digest Auth还是其他？

   • curl 示例：

 # Basic Auth示例
 curl -u "username:password" http://your-api-endpoint/secure-resource
 
 # Bearer Token示例
 TOKEN="your_jwt_or_api_token"
 curl -H "Authorization: Bearer ${TOKEN}" http://your-api-endpoint/secure-resource

3. 服务器端开发者：

   • 返回WWW-Authenticate头： 当返回401时，应在响应中包含WWW-Authenticate头，告知客户端服务器支持哪些认证方案以及如何进行认证。

   http
   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Bearer realm=“example”, error=“2invalid_token”, error_description=“The access token expired”

   Content-Type: application/json

   {“error”: “invalid_token”, “error_description”: “The access token expired”}

   • 清晰的认证失败日志： 在服务器端记录详细的认证失败原因（如“token不存在”、“token签名验证失败”、“token过期”、“用户不存在”、“密码错误”等），但注意不要在公开的错误信息中泄露过多敏感细节。

   • 检查认证逻辑： 确保服务器端的认证模块（如Spring Security配置、JWT校验逻辑）工作正常。

总结：从容面对Web世界的“小意外”

今天我们一起“会诊”了Web开发中几个最令人头疼的“常客”：502、503、“Connection reset”、504、400和401。默语希望通过这些场景化的比喻、原因分析和排查步骤，能让你对它们有一个更清晰、更深入的理解。

记住几个关键点：

• 日志是王道： 无论是客户端还是服务器端，详细的日志是排查问题的第一手资料。

• 理解HTTP语义： 明白每个状态码代表的通用含义，能帮你快速缩小问题范围。

• 区分责任方： 4xx通常是客户端的错，5xx通常是服务器端的错（或者是网关与上游服务器之间的问题）。

• 系统性排查： 从客户端 -> 网络 -> 网关/代理 -> 应用服务器 -> 依赖服务，逐层排查。

• 工具善其事： 熟练使用浏览器开发者工具、 curl、Postman、Wireshark/tcpdump、以及服务器端的各种监控和日志分析工具。

Web开发就是一个不断遇到问题、分析问题、解决问题的过程。当你能从容地面对这些错误码，并快速定位到根源时，你就离一名优秀的Web开发者又近了一步！

---

觉得默语的分享对你有帮助吗？Web的世界充满了挑战和乐趣，如果你在开发中遇到了其他棘手的问题，或者对今天的内容有任何疑问和心得，都非常欢迎添加我的微信 [你的微信号]，备注“Web错误排查”，我们可以一起交流学习，共同进步！期待与你一起探索更多Web技术的奥秘！

参考资料：

• MDN Web Docs - HTTP状态码：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status

• Nginx官方文档 (对于502, 504排查非常有帮助)：https://nginx.org/en/docs/

• Wireshark官方网站 (网络抓包分析工具)：https://www.wireshark.org/

• curl
  

  命令手册：查阅你的操作系统

  man curl
  

---

---

如对本文内容有任何疑问、建议或意见，请联系作者，作者将尽力回复并改进📓；( 联系微信:Solitudemind )

点击下方名片，加入 IT 技术核心学习团队。一起探索科技的未来，共同成长。

为了让您拥有更好的交互体验，特将这行文字设置为可点击样式：点击下方名片，加入 IT
技术核心学习团队。一起探索科技的未来，共同成长。