Web 服务器怎么选

很多人第一次部署网站的时候，面对 Nginx、Apache、Tomcat、Caddy、Traefik 这堆名词会懵一下。它们做的事情有重叠，但定位差异很大。

先分清两个概念：Web 服务器和应用服务器

混在一起说容易乱。

Web 服务器（HTTP 服务器）干的事比较纯粹：收 HTTP 请求，返回响应。擅长静态文件托管、反向代理、TLS 终结、负载均衡。代表是 Nginx、Apache、Caddy。

应用服务器是跑业务代码的运行时。你写的 Java Servlet、Python ASGI 应用，需要一个东西把它跑起来，监听端口，把请求喂给代码处理。Tomcat 是 Java 的，uvicorn 是 Python 的，Puma 是 Ruby 的。

有些工具两个都能干，但擅长的不一样。Nginx 也能跑 Lua 脚本，但没人拿它写业务逻辑。Tomcat 也能托管静态文件，但性能和便利性比 Nginx 差一截。

Apache：老牌劲旅，没退役但也没新增量

1995 年发布，曾经占据全球 Web 服务器市场 60% 以上。现在份额一直在降，但存量巨大，传统企业 IT 和共享主机环境里到处都是。

Apache 的核心是模块化设计。mod_rewrite 做 URL 重写，mod_ssl 做 HTTPS，mod_php 直接嵌入 PHP 解释器。.htaccess 文件让每个虚拟主机都能自己改配置，共享主机时代这个功能很重要。

它默认用 prefork 模式，每个连接一个进程。好处是稳定，坏处是内存吃得多。几百并发连接就能把内存撑爆。后来加了 event 模式，走 epoll，性能好了不少，但 Nginx 已经抢走了心智。

我见过一个 PHP 站点跑在 Apache prefork 上，流量一上来就 OOM。换到 Nginx + PHP-FPM 之后同样配置扛住了。prefork 模型在高并发下天然吃亏。

Nginx：反代之王，事实标准

2004 年由俄罗斯工程师 Igor Sysoev 发布，最初是为了解决 C10K 问题，一台机器扛一万个并发连接。事件驱动，单进程多 worker，每个 worker 用 epoll 处理大量连接。

Nginx 的反向代理能力是它最核心的价值。大部分公司的架构都是：Nginx 在前面做反代、TLS、负载均衡，后面挂一堆应用服务器。不管应用是 Java、Python、Go 还是 Node，前面放个 Nginx 总不会出错。

配置文件是这个风格：

upstream backend {
server 127.0.0.1:3000;
server 127.0.0.1:3001;
}

server {
listen 443 ssl;
server_name example.com;

ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;

location / {
proxy_pass http://backend;
}

location /static/ {
root /var/www;
expires 30d;
}
}

不算复杂，但东西一多就容易乱。location 匹配优先级、rewrite 规则的执行顺序、upstream 的健康检查参数，这些细节需要时间消化。

Nginx 的短板在 HTTPS 证书管理。得自己跑 certbot，自己配 crontab 续期，自己写 reload 脚本。不难，但繁琐。另外配置语法不是标准格式，没法用 JSON 或 YAML 解析，自动化管理配置比较麻烦。

Tomcat：不是同一层的东西

Tomcat 是 Java Servlet 容器，跑 Java Web 应用的。它和 Nginx、Apache 不在一个赛道。

Spring Boot 默认内嵌 Tomcat，java -jar app.jar 启动，Tomcat 就在里面了。大部分 Java 开发者其实不会直接去配 Tomcat，而是通过 Spring Boot 的配置文件间接控制。

Tomcat 也能做 HTTP 服务器和静态文件托管，但这是它的副业。拿 Tomcat 当反向代理用？能做，配置比 Nginx 麻烦，性能也差。见过有人这么干，后来老老实实加了层 Nginx。

生产环境的标准做法是 Nginx 在前，Tomcat 在后。Nginx 处理 TLS、静态文件、压缩，Tomcat 专注跑 Java 应用，两者之间用 AJP 或 HTTP 协议通信。

Caddy：省心到不像话

2015 年发布，Go 写的。最大卖点就一个词：自动 HTTPS。

写上域名，Caddy 启动时自动向 Let’s Encrypt 申请证书，自动配好 443 和 HTTP→HTTPS 跳转，自动续期，续完自动 reload。不用装 certbot，不用写 crontab，不用管证书过期。

配置文件短到让人怀疑是不是漏了什么：

example.com {
reverse_proxy localhost:3000
}

证书、跳转、TLS 版本协商、HTTP/2、HTTP/3，全是默认行为。

Caddy 省的不只是证书。它的配置语法（Caddyfile）比 Nginx 简洁很多，合理默认值覆盖了大部分常见场景。反代、静态文件、负载均衡、路径重写，几行搞定。

大部分场景能替代 Nginx。个人项目、中小型服务、内部工具，Caddy 的体验明显更好。

但有几个地方 Caddy 偏弱。Nginx 的 location 正则匹配非常灵活，复杂路由规则写起来得心应手，Caddy 的 matcher 语法要绕一下。超大规模调优方面，Nginx 的 worker 配置、连接数控制更成熟。Caddy 社区文档少，遇到冷门问题不一定搜得到答案。

还有一个坑：Caddy 的自动 HTTPS 依赖公网域名和 80/443 端口可达。内网环境、没有公网 IP 的场景，自动申请会失败，得手动配证书。这时候 Caddy 的核心优势就没了，和 Nginx 拉不开差距。

Traefik：容器时代的反代

2016 年发布，也是 Go 写的。Traefik 的定位和前面几个不太一样，它是为容器化和微服务架构设计的。

核心能力是自动服务发现。用 Docker Compose 或 Kubernetes 跑了一堆服务，Traefik 能自动感知容器上线下线，自动更新路由规则，不用手动改配置。加了个新微服务？Traefik 自动发现，自动把流量导过去。

Nginx 也能做，但需要配合外部工具（比如 ingress-nginx controller + ConfigMap），链路比较长。Traefik 把这些打包好了，开箱即用。还自带一个 Dashboard，可视化看路由关系，调试时挺方便。

代价是配置概念多。entrypoints、routers、services、middlewares，学习曲线比 Caddy 陡。如果不是容器环境，Traefik 的优势发挥不出来，反而比 Nginx 麻烦。裸机上跑传统单体应用，我不会选 Traefik。

框架自带的服务器：开发够用，生产要斟酌

很多语言和框架自带 HTTP 服务器，但得区分哪些只能开发用，哪些能上生产。

Python 的 http.server 是标准库里的，单线程，没有任何并发处理能力。拿来本地调试静态文件没问题，放生产就是灾难。一个请求卡住，后面全部排队等。

FastAPI 的 uvicorn 不一样。它是 ASGI 服务器，基于 uvloop（libuv 的 Python 绑定），异步 IO，性能不错。小项目直接用 uvicorn 跑 FastAPI 上生产，问题不大。但流量大了之后通常还是会在前面加一层 Nginx：TLS 终结交给 Nginx，应用服务器不用管证书；静态文件 Nginx 处理更快；Nginx 能做请求缓冲和限速，保护后端。见过一个 Python 服务直接裸跑 uvicorn 暴露在公网，被慢速攻击打满了连接数，加了一层 Nginx 做限速才稳。

Gunicorn 是另一个常见选择，WSGI 服务器，用 pre-fork worker 模型。同步 worker 稳定但并发弱，异步 worker（gevent）并发好但对 C 扩展有兼容问题。Django 项目常用 Gunicorn。

Go 语言比较特殊。标准库的 net/http 直接就是生产级 HTTP 服务器，性能很好。很多 Go 项目不需要前面再放一层 Nginx。TLS 用 autocert 包也能自动申请 Let’s Encrypt 证书。当然，反代、负载均衡、多实例这些场景还是需要独立的 Web 服务器。

Node.js 的 http 模块也能直接跑，但生产环境一般用 PM2 管理进程，前面挂 Nginx。单线程的 Node 进程挂了就全挂，需要进程管理器和反代兜底。

我怎么看

静态站点或简单反代，Caddy 最省心，配置短，证书不用管。如果已经在用 Nginx 且没有痛点，没必要换。Nginx 稳定、文档全、运维都熟。

Java 应用，Tomcat 跑业务，前面放 Nginx 做 TLS 和静态文件，这是标准操作。

容器化微服务架构，Traefik 值得看，自动服务发现省很多事。Kubernetes 环境里 ingress-nginx 也是主流选择，两者各有取舍。

Python 项目，小流量直接 uvicorn 或 Gunicorn 跑，流量大了前面加 Nginx。Go 项目标准库够用，需要反代和多实例时再加 Nginx 或 Caddy。

技术选型看团队、看存量、看场景。一个全 Java 的团队不会因为"Caddy 更省心"就去换技术栈，一个刚起步的个人项目也没必要上来就 Nginx + Tomcat 全家桶。工具是手段，顺手最重要。