从零手写HTTP服务器：彻底搞懂协议、Socket与500/502状态码

前段时间在折腾网络编程，最深的体会是：很多人每天被各种 HTTP 报错折磨，比如状态码 400、404、502、unexpected status 502 bad gateway，但真要问一句"HTTP 服务器收到请求后到底做了什么"，大多数人是答不上来的。技能树缺了关键一环，排错就只能靠猜。所以我想，与其对着报错瞎试，不如从零手写一个 HTTP 服务器，把协议内部那一套流程彻底跑通。

这个项目不像搭 Nginx、写 Spring Boot 那么"省事"，但它能让你把网络编程中最底层、最核心的东西吃透。不管你是刚学完 socket 编程的学生，还是工作中经常和网络接口打交道、被各种状态码搞得焦头烂漏的开发者，跟着完整实现一遍，对 HTTP 协议的理解会上一个台阶。本文会从协议最核心的流程讲起，逐步实现一个支持静态文件服务、能处理常见请求、可扩展为多线程的 HTTP 服务器，中间穿插我在实际写代码时踩过的坑和验证方法。

1. 动手之前：HTTP 服务器到底要干哪些活

先说一个反直觉的结论：一个 HTTP 服务器，抛开性能、安全、各种高级特性，核心要做的事情只有六步——接受连接、读取请求字节流、解析请求行和请求头、路由到对应处理逻辑、构建响应、发送响应。一切看起来复杂的功能，都是在这些基础动作之上叠加的。

1.1 一次 HTTP 请求的完整旅程

我习惯把 HTTP 服务器比作一个餐厅服务员。客人（客户端）落座后先与服务生打个照面（TCP 三次握手建立连接），然后点菜（发送 HTTP 请求报文），服务生记录点单内容（服务器解析请求），把菜单传给后厨（路由分发），后厨做好菜（处理逻辑生成响应体），服务生把菜端上来（服务器发送响应报文），最后客人结账离开（关闭连接或保持长连接）。

在技术层面，一次完整的请求是这样的：

1. 客户端通过 http://127.0.0.1:8080/index.html 这样的 URL 发起访问。
2. 浏览器或 curl 通过 DNS 解析拿到 IP，通过端口号定位到服务器的监听 socket，完成 TCP 三次握手。
3. 客户端按照 HTTP 协议格式，往 TCP 连接写入一段字节流，例如：

code复制GET /index.html HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: curl/8.0.1
Accept: */*

4. 服务器在 accept 到这个连接后，循环 recv 读取这段字节流，直到确认拿到完整的请求数据。
5. 服务器按 HTTP 协议的规则切分这段字节流，得到请求方法（GET）、路径（/index.html）、协议版本（HTTP/1.1）以及一堆头部字段。
6. 服务器根据路径找到对应资源或处理函数，生成状态行、响应头和响应体。
7. 服务器通过 socket 把响应字节流写回给客户端。
8. 客户端解析响应，展示页面或保存文件。

1.2 服务器实现的最小必要功能清单

在我的实现中，把 "HTTP 服务器" 拆成了四个必须完成的能力：

• 监听与连接管理：创建一个 TCP socket，绑定 IP 和端口，进入监听状态，循环接受新连接。
• 请求解析：把 socket 中读到的字节流，解析成一个包含请求方法、路径、HTTP 版本、请求头字典、请求体数据的结构化对象。
• 路由与响应生成：根据路径和请求方法分发到不同的处理函数，处理函数返回一个包含状态码、响应头、响应体的结果对象。
• 静态文件服务：从磁盘读文件并返回，涉及 MIME 类型映射、文件不存在时返回 404、路径穿越防护。

这四件事看着简单，但每一件都藏着一堆细节——请求边界怎么判断、Content-Length 和 Connection 头怎么处理、文件路径要不要做安全校验。下面逐一展开。

2. Socket 层骨架：连接怎么建立、怎么收数据

HTTP 是应用层协议，底层靠 TCP 传输数据。所以第一步是搭建一个 TCP 服务器骨架。我用 C 语言实现过，也用过 Python 的 socket 模块做原型验证，核心逻辑完全一致，这里以更易读的伪代码风格展示，方便你迁移到自己熟悉的语言。

2.1 核心 API 与监听循环

一个典型的 TCP 服务器骨架是这样的：

c复制// 1. 创建 socket
int server_fd = socket(AF_INET, SOCK_STREAM, 0);

// 2. 设置 SO_REUSEADDR，解决 TIME_WAIT 导致的端口占用问题
int opt = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

// 3. 绑定 IP 和端口
struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_ANY;  // 监听所有网卡
addr.sin_port = htons(8080);
bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));

// 4. 进入监听状态，backlog 表示等待队列长度
listen(server_fd, 128);

// 5. 主循环：接受连接并处理
while (1) {
    int client_fd = accept(server_fd, NULL, NULL);
    handle_client(client_fd);  // 先实现单线程版
    close(client_fd);
}

几个容易踩的坑：

• SO_REUSEADDR 必须设置。否则服务器崩溃后立即重启时，因为上一轮连接还处于 TIME_WAIT 状态，bind 会报 Address already in use，这是新手最容易遇到又最难排查的问题之一。
• 监听地址用 INADDR_ANY 还是 127.0.0.1。如果只在本机调试，用 127.0.0.1 更安全，外网访问不到；想被局域网其他机器访问，用 INADDR_ANY。我一开始默认用了 INADDR_ANY，结果内网其他机器也能访问，虽然测试方便，但你需要意识到这是有安全隐患的。
• accept 返回的 client_fd 是一个全新的 socket，专门用于和当前客户端通信。真正收发数据的操作都基于 client_fd，server_fd 只负责接收新连接。

2.2 粘包和半包：读数据时最容易踩的坑

TCP 是字节流协议，没有消息边界。这意味着你 recv 一次得到的字节数，不一定是完整的一个 HTTP 请求——可能只读到了一半（半包），也可能一次读到了两个请求拼接在一起（粘包）。

我第一次写的时候就是只 recv 一次就解析，结果浏览器访问时随机出现解析失败，后来才明白这个道理。正确的读取策略是循环读取，直到累积的字节流构成一个完整的 HTTP 报文。判断完整性的标准有两种：

• 简易方案：读到的字节流中出现了 \r\n\r\n（即空行），说明请求头完整了。如果方法带有请求体（如 POST），还要根据 Content-Length 头判断 body 是否也到齐了。
• 严谨方案：用状态机跟踪当前解析到了请求的哪一部分，每一部分都累积到缓冲区中，直到所有部分都齐全。

c复制int read_until_complete(int client_fd, char *buffer, int *buf_len) {
    // 大循环：每次多读一点，并检查是否已构成完整 HTTP 报文
    while (1) {
        // 查找是否已出现 \r\n\r\n，且 body 长度足够
        if (is_http_message_complete(buffer, *buf_len)) {
            break;
        }
        ssize_t n = recv(client_fd, buffer + *buf_len, BUF_SIZE - *buf_len, 0);
        if (n <= 0) {
            // 对端关闭连接或出错
            break;
        }
        *buf_len += n;
    }
    return *buf_len;
}

注意：recv 返回 0 表示客户端正常关闭了连接，返回 -1 且 errno 为 EINTR 表示被信号中断，应该重试，而 ECONNRESET 表示对端强制重置连接。不理解这些错误码，就很容易写出"偶发崩溃"的服务器。

2.3 超时、缓冲与错误处理

实际项目里不可能让一个连接永远吊着，所以必须给 socket 设置超时：

c复制struct timeval tv = { .tv_sec = 5, .tv_usec = 0 };
setsockopt(client_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
printf("\n"); // 空操作，保持结构

缓冲区设计也要注意：读缓冲区通常开 4KB~8KB，但一个请求头可能超过这个大小（比如携带很大的 Cookie）。如果你只开固定缓冲区，读到超过一半就截断，解析逻辑就崩了。解决办法是动态扩容缓冲区，或者在读满后重新分配一块更大的。我的经验是：先分配固定 8KB，如果 is_http_message_complete 返回未完成且缓冲区已满，就 realloc 翻倍，继续读。这样既不会频繁分配内存，又能处理超大请求头。

3. 请求解析：将字节流变成可理解的结构体

现在拿到了完整的请求字节流，下一步是解析。这是整个项目里最体现 "协议" 二字精髓的部分，也是以后你看各种网络框架源码时最容易产生亲切感的环节。

3.1 请求行、请求头、请求体的分割边界

先看标准 HTTP/1.1 请求报文的结构：

code复制<请求行>
<请求头字段>...
<空行>
<请求体，可选>

具体到字节流里的样子是：

code复制<METHOD> <SP> <URL> <SP> <HTTP版本>\r\n
<字段名>: <字段值>\r\n
...
\r\n
<请求体数据>

关键点是这三处分隔：

• 请求行和第一个请求头之间用一个 \r\n 分隔。
• 每个请求头之间用 \r\n 分隔。
• 最后一个请求头与请求体之间用一个空行，也就是 \r\n\r\n。

这解释了为什么判断请求头是否完整要看 \r\n\r\n。不只是人为定义，也是解析器分割数据的依据。我在实现时把解析逻辑写成了这样：

c复制typedef struct {
    char method[8];       // GET, POST, PUT...
    char path[1024];      // 解码后的路径
    char version[16];     // HTTP/1.0, HTTP/1.1
    // 用链表或 map 保存所有请求头
    Header headers[MAX_HEADERS];
    int header_count;
    char *body;           // 请求体
    size_t body_len;
} HttpRequest;

int parse_http_request(const char *buf, size_t len, HttpRequest *req) {
    // 第一步：按 \r\n 拆出第一行
    const char *line_end = strstr(buf, "\r\n");
    if (!line_end) return -1;
    // 第一行格式: METHOD SP PATH SP VERSION
    sscanf(buf, "%7s %1023s %15s", req->method, req->path, req->version);
    
    // 第二步：逐行解析请求头，直到空行
    const char *p = line_end + 2;
    while (p < buf + len && !(p[0] == '\r' && p[1] == '\n')) {
        // 找到头部行结尾
        const char *header_end = strstr(p, "\r\n");
        // "Name: Value" 用冒号分割，Value 前的空格要去掉
        const char *colon = strchr(p, ':');
        ...
        p = header_end + 2;
    }
    
    // 第三步：如果请求头之后还有数据，且存在 Content-Length，按长度切分 body
    ...
    return 0;
}

3.2 解析器设计：状态机还是逐行拆分

我最初用 "先按 \r\n 拆行，再按冒号拆字段" 的简单方式，写起来直白，但遇到半包时要自己拼凑数据，不太优雅。后来参考了一些开源代码，改成状态机方式，觉得更适合处理流式数据。

状态机把解析过程拆成几个状态：

• STATE_METHOD：读取请求方法。
• STATE_PATH：读取请求路径。
• STATE_VERSION：读取协议版本和换行。
• STATE_HEADER_START：准备读取下一个头字段。
• STATE_HEADER_NAME：读取字段名，遇到冒号切到 VALUE。
• STATE_HEADER_VALUE：读取字段值，遇到换行完成一个头。
• STATE_BODY：进入请求体读取。

每读入一个字节，就根据当前状态决定"这个字节属于哪个部分"，状态不断迁移，直到报文结束。好处是不用一次性凑齐完整报文，可以边读边解析。但作为入门项目，用逐行拆分完全够。我的建议是：先用拆行法跑通，再去看状态机实现，理解会更深刻。

3.3 解析之后的路由分发逻辑

解析得到 method 和 path 之后，就要做路由分发。最简单的做法是写一个映射表：

c复制if (strcmp(req->method, "GET") == 0 && strcmp(req->path, "/") == 0) {
    // 首页
} else if (strcmp(req->method, "GET") && strncmp(req->path, "/static/", 8) == 0) {
    // 静态资源
} else {
    // 404
}

更好的做法是设计一个路由表，支持注册处理函数：

c复制typedef void (*handler_t)(HttpRequest *req, HttpResponse *res);

typedef struct {
    const char *method;
    const char *path_pattern;
    handler_t handler;
} Route;

Route routes[] = {
    {"GET", "/", handle_index},
    {"GET", "/health", handle_health},
    {"POST", "/api/echo", handle_echo},
};

执行时按顺序遍历路由表，支持简单的通配符匹配（比如 /static/* 匹配所有静态资源）。这里有一个细节：URL 解码。浏览器请求 %E4%B8%AD%E6%96%87 这样的百分号编码路径时，服务器解析得到的是原始编码字符串，你要手动做一次 URL decode，转成 /中文 再去映射文件。否则用户访问 http://127.0.0.1:8080/%E4%B8%AD%E6%96%87.html 会 404。

4. 响应构建与静态文件服务：让浏览器真的能看到东西

解析完请求，就要回东西了。很多第一次实现服务器的同学，在这里踩了一个超级隐蔽的坑：响应头没写 Content-Length，导致浏览器一直转圈或者页面空白。

4.1 一个完整的响应报文长什么样

响应报文的结构和请求是对称的：

code复制<状态行><SP>
<响应头>...
<空行>
<响应体>

例如：

code复制HTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Length: 31\r\n
Connection: close\r\n
\r\n
<html><body>Hello</body></html>

关键是 Content-Length 这个头。它告诉客户端响应体有多长，好让客户端知道读到几个字节算完。如果不写，客户端（尤其是 HTTP/1.1 协议）会一直等，直到连接关闭才发现响应结束。在 Connection: close 模式下，服务器发送完数据后主动关闭连接，浏览器还能通过连接关闭判断结束；但如果开了 Keep-Alive，不写 Content-Length 就完全没法判断，浏览器就一直转圈。

还有一个更隐蔽的问题：响应头中的 Content-Length 跟请求体中的 Content-Length 含义一样，都是"当前报文体长度"，但绝不能混用。我在一开始写代码时复用了一个全局变量，结果处理 POST 之后再发响应，长度就错了，客户端收到的响应与实际数据对不上。

4.2 静态文件服务的特殊之处：路径穿越与文件找不到

做静态文件服务时，最核心的代码是"把 URL 路径映射到磁盘路径"。常见做法是：

c复制// 将请求路径解析为本地文件路径
const char *base_dir = "./www";
char file_path[1024];
snprintf(file_path, sizeof(file_path), "%s%s", base_dir, req->path);

这写起来很简单，但潜藏一个经典漏洞：路径穿越。如果用户请求的路径是 /../../etc/passwd，拼接之后就成了 ./www/../../etc/passwd，服务器就会读取系统文件并返回给客户端，这是非常严重的安全漏洞。

防护办法就一条：先把路径做标准化，再检查标准化后的结果是否还在 base_dir 目录内。示例逻辑：

c复制#include <limits.h>
#include <stdlib.h>

char resolved[PATH_MAX];
// realpath 会把 ../ 等符号链接解析成绝对路径
if (realpath(file_path, resolved) == NULL) {
    // 文件不存在
    send_404(res);
    return;
}
if (strncmp(resolved, base_dir, strlen(base_dir)) != 0) {
    send_403(res);   // 越界访问，拒绝
    return;
}

这一点在你自己的服务器里必须做。就算只是本地学习项目，形成路径校验的习惯也很有价值，因为这项工作到了真实项目中就是安全评审的必备项。

另外，请求路径是 / 时要映射到 index.html，这是 Web 服务器最基础的约定。路径不存在时，返回标准 404 页面：

code复制HTTP/1.1 404 Not Found\r\n
Content-Type: text/plain\r\n
Content-Length: 13\r\n
Connect: close\r\n
\r\n
404 Not Found

4.3 Content-Type 映射与图片文件的分块读取

响应里还有一个容易让页面"乱码"的坑：Content-Type。不同后缀名对应不同 MIME 类型。如果你把所有文件都返回成 text/plain，浏览器访问 .jpg 时会把图片当文本显示；访问 .html 时中文会出现乱码。至少要准备这样一张映射表：

图片这类大文件需要注意：不要用一次 recv/read 把整个文件读进内存再发出去，4MB 的图片小事，4GB 的视频就内存爆了。正确做法是用 fopen 打开文件，获取文件大小，然后把文件大小填入 Content-Length，再用一个固定缓冲区（比如 64KB）循环从文件里读数据、写到 socket：

c复制FILE *fp = fopen(file_path, "rb");
fseek(fp, 0, SEEK_END);
long file_size = ftell(fp);
fseek(fp, 0, SEEK_SET);

// 先拼响应头，再把文件内容作为响应体发出去
char header[1024];
snprintf(header, sizeof(header),
         "HTTP/1.1 200 OK\r\n"
         "Content-Type: %s\r\n"
         "Content-Length: %ld\r\n"
         "Connection: close\r\n"
         "\r\n",
         mime_type, file_size);
send(client_fd, header, strlen(header), 0);

char buf[65536];
size_t n;
while ((n = fread(buf, 1, sizeof(buf), fp)) > 0) {
    send(client_fd, buf, n, 0);
}
fclose(fp);

5. 并发能力升级：从单线程到长连接改造

基础版本只能同时处理一个连接，处理完一个客户端才 accept 下一个，这在真实场景完全不够用。但这正是进阶的好机会。

5.1 为什么单线程够用但不够看

单线程模型的最大问题是：一个客户端如果连接后一直不发送数据（或者发送很慢），服务器就阻塞在 recv 上，后面的所有客户端都被晾着。这也解释了为什么很多网络程序要加超时——如果没有超时，一个半死不活的连接能把整个服务拖死。

我的第一版实现就是单线程，用 curl 测试时还好，因为 curl 一上来就发完请求等着收响应，服务器处理很快。但用浏览器打开页面，浏览器会同时发起多个请求（HTML、CSS、JS），如果服务器只能串行处理，每个请求都要等上一个完事，能明显感到卡顿。

5.2 多线程 vs 线程池：实际选择与陷阱

最简单的优化是"每连接一线程"：accept 到一个连接就创建一个线程去处理，主线程继续 accept：

c复制while (1) {
    int client_fd = accept(server_fd, NULL, NULL);
    pthread_t tid;
    pthread_create(&tid, NULL, handle_client_thread, &client_fd);
    pthread_detach(tid);  // 分离线程，退出后自动回收资源
}

这个模型能解决并发问题，但建线程有开销，高频短连接场景下频繁创建销毁线程会浪费大量资源。更实用的方案是线程池——预先创建固定数量线程，任务队列用互斥锁和条件变量来同步。

我实际测试中踩了一个典型的多线程坑：如果 handle_client_thread 里用到全局变量（比如记录访问次数的计数器），多个线程同时写会冲突。解决方法是加锁或者用线程局部变量。这类"共享资源竞争"问题在真实的高并发环境会被放大，所以一开始就要有意识地设计。

5.3 Keep-Alive 与头部再解析

默认 HTTP/1.1 是长连接（Keep-Alive），也就是说客户端可以在同一个 TCP 连接上发送多个请求。这能避免反复握手，但给服务器实现增加了难度：处理完一个请求后不能立即 close 连接，而是要回到读取状态，继续等待下一个请求。

实现 Keep-Alive 需要做到三点：

1. 判断请求头中的 Connection 字段。如果是 keep-alive，在响应头里也要写 Connection: keep-alive，然后继续循环读取；如果是 close，则响应头写 Connection: close 并关闭连接。
2. 每次读请求都要重新解析，不能把上一个请求残留的数据当成新请求的一部分。
3. 每次读请求都需要有超时保护——客户端空闲太久，继续傻等占用线程资源，合理做法是直接关闭。

实现伪代码：

c复制int keep_alive = 1;
while (keep_alive) {
    if (!read_complete_request(client_fd, &req)) {
        break; // 客户端断开或超时
    }
    handle_request(&req, &res);
    send_response(client_fd, &res);
    
    // 根据请求头决定是否继续
    if (strcasecmp(get_header(&req, "Connection"), "close") == 0) {
        keep_alive = 0;
    }
    // 清理本次请求数据，进入下一轮循环
    reset_request(&req);
}

这个改造做完，你的服务器就已经具备"商用服务器基础形态"了。再往后走，就是 epoll/kqueue 等事件驱动模型、零拷贝、异步 IO 这些更深的优化话题，但那是另一个层级的问题了。

6. 功能验证与线上排错：你的服务器真的对吗

代码写完了，怎么证明它是对的？我见过不少同学，代码写完一跑浏览器能出页面，就觉得完事了，但真真假假的问题其实很多。这里分享一套我常用的验证和排错方法。

6.1 用 curl 和浏览器验证核心功能

第一步用 curl -v 看请求和响应全貌。-v 参数会打印完整交互过程，包括请求头、响应头、响应体，是调试 HTTP 服务最趁手的工具：

bash复制curl -v http://127.0.0.1:8080/index.html

输出大概是：

code复制* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /index.html HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.0.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 31
< Connection: close
< 
<html><body>Hello</body></html>

这一步能确认服务器发的响应头是否正确、状态码是否正确。我强烈建议你养成习惯：每次改完代码，先用 curl -v 看一遍完整交互，再打开浏览器确认渲染效果。不要一上来就用浏览器，浏览器会隐藏很多细节。

第二步测各种边界情况：

bash复制# 访问不存在的路径，期待 404
curl -v http://127.0.0.1:8080/nonexistent.html

# 用 HEAD 方法请求，期待服务器只回响应头、不回响应体
curl -I http://127.0.0.1:8080/index.html

# 乱写路径，期待 400 或 404
curl -v "http://127.0.0.1:8080/%zz"

6.2 HTTP 状态码自查：404、400、502 这些报错到底是谁的问题

结合开头提到的热搜词——很多人被 502 Bad Gateway、404 Not Found、400 Bad Request 这类报错困扰，但不知道根因。实现完自己的服务器后，我对这些状态码的理解明显清晰了：

• 400 Bad Request：服务器认为请求报文语法错误。比如请求行格式不对、缺了 Host 头（HTTP/1.1 强制要求）、解析头时发现非法字符。你自己写服务器时，遇到解析失败就应该回 400。
• 404 Not Found：路径对应的资源不存在。可能路由没匹配上，也可能磁盘上没有对应文件。
• 502 Bad Gateway：这个状态码很有迷惑性。它通常出现在反向代理场景，比如 Nginx 作为代理，转发给上游服务器时，上游返回了非法响应或根本没有响应，代理层就会回 502。当你自己写服务器时，如果哪天你要实现一个代理转发功能，上游响应格式不规范，它就变成了你这边要处理的核心问题。502 的排查思路往往不在客户端，而在代理层与上游服务之间。
• 500 Internal Server Error：服务器内部逻辑异常。比如处理函数抛异常、文件读取失败却没捕获。

现在再看那些热搜词里的报错，unexpected status 502 bad gateway: unknown error、cc switch local proxy failed while handling codex endpoint 这类问题，本质上下游网关的响应处理异常。理解了 HTTP 协议层的工作机制，再去排查这类问题就有方向感了。

6.3 兼容性细节：HTTP/1.1、Host 头、Content-Length 大小写

最后提几个细节，都在真实场景中踩过：

• 响应头字段名大小写不敏感。content-length 和 Content-Length 一样。但你的服务器在解析请求头时，也要大小写不敏感地处理字段名，比如 Host 和 host 是一样的。推荐统一转成小写或者用 strcasecmp。
• HTTP/1.1 要求请求必须带 Host 头。协议规定，HTTP/1.1 的请求报文如果缺少 Host 头，服务器应该返回 400。浏览器肯定带了，但写脚本或测试时容易漏。
• HTTP/1.1 默认 Keep-Alive。如果你的服务器只实现了 HTTP/1.0 风格的一次性连接，浏览器也能工作（因为浏览器在响应头看到 Connection: close 后会自动处理），但性能差。反过来，如果你响应头没写 Content-Length 又没写 Connection: close，浏览器会长期悬挂。
• curl 访问 http://127.0.0.1:8080 时，请求行通常是 GET / HTTP/1.1，路径是 / 而不是空字符串，所以服务器要做根路径到 index.html 的映射或默认页处理。

结尾：写给你的一点个人体会

做完这个项目后，我最明显的感受是：以后再遇到 HTTP 报错，第一反应不再是"网上搜搜是什么错误"，而是先想"这个错误出现在协议栈的哪一层"——是连接层、解析层、路由层还是代理转发层。这种分层定位问题的思路，比背状态码表管用得多。

如果要说一个最重要的建议：在调试你的服务器时，永远先确认自己发的响应头和响应体严格符合协议规定。很多时候客户端报错不是客户端的问题，而是服务端返回的数据不合规。养成用 curl -v 验证的习惯，你会少走很多弯路。

这个项目的代码量不大，但值得反复迭代。我第一版只有 200 多行，后面一步步加了 Keep-Alive、多线程、路径校验、MIME 映射，最后也才 800 行左右。你完全可以在我的思路上继续加功能，比如支持 POST 表单解析、加一个简单的日志模块、甚至写一个简化版的反向代理——那时候你会发现，那些平时看到的 HTTP 报错，背后都是这套基础逻辑的延伸。