我们平时在服务器上，肯定不是直接暴露端口，让外界访问，而是使用反向代理。很简单，因为反向代理好处多，除了更方便管理、限流等等、可以把请求给分给很多后端服务，避免单点过载。为服务器分担压力。

当然，nginx 还能压缩一下内容、而且集中处理 ssl 这种加密解密，复用 TCP 连接（或者说减少 TCP 三次握手的开销），毕竟 nginx 是与后端长连接的。而且 nginx 就是为并发设计的，就算你懒得搞缓存，也是有莫大的优势。

我想起来我之前，有记过一个三个主流代理软件在选择上的笔记，顺便整理一下分享分享：

主流的三个反向代理软件

现在主流的成熟的反向代理软件，有三个：Traefik、Nginx、Caddy 。

（注意，Apache 它本质是一个 web 服务器，它已经没落，而且不是专门搞反向代理的）

其中，nginx 是最流行的。但是这三种，每种都有它适合的地方。

在我印象中大体来讲，nginx 用的最多。

微服务方面，Traefik 更有优势。

简洁优雅方面，caddy 最简单（尤其是配置，最简单，而且自带 Let's Encrypt 和 ZeroSSL ，搞 SSL 证书很省劲！）。

我来给大家讲一下什么场景、以及它们都有什么区别。

区别

它们三种，在成分上，有以下几个区别：

可以看到 nginx 这个老牌反代理工具，在 内存占用方面非常优秀。因此，这也是为什么 Nginx 用的最广泛了。

配置文件复杂度

配置方面，最复杂的就是 Nginx ，这个不再多说，看着就头疼。

而 Traefik 的配置长这个样子，是 YAML 格式的，维护起来还算可以：

services:
  traefik:
    image: traefik:v3.1
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.email=you@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/acme/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
    ports: ["80:80", "443:443"]
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./acme:/acme

  api:
    image: my-api:latest
    labels:
      - "traefik.http.routers.api.rule=Host(`api.example.com`)"
      - "traefik.http.routers.api.tls.certresolver=letsencrypt"
      - "traefik.http.services.api.loadbalancer.server.port=3000"

  frontend:
    image: my-frontend:latest
    labels:
      - "traefik.http.routers.frontend.rule=Host(`app.example.com`)"
      - "traefik.http.routers.frontend.tls.certresolver=letsencrypt"
      - "traefik.http.services.frontend.loadbalancer.server.port=8080"

但是，最简单的是 caddy ，配置是使用 JSON 格式（或称为 Caddyfile）来声明：

api.example.com {
    reverse_proxy localhost:3000
}

app.example.com {
    reverse_proxy localhost:8080
}

证书 TLS 和配置方面

对于配置 SSL （TLS）方面，最友好的是 caddy ，一切自动搞定，而且还能自动续费，而 Traefik 和 Nginx 都需要单独配置。而且 Nginx 还得搞个 ACME 客户端，这个最麻烦。

而对于配置。

Nginx 默认是静态配置，你修改了配置文件，得重载（nginx -s reload）才能启动。不过，使用 nginx-proxy 是可以实现动态配置的。

caddy 是动态配置的，它有 API 接口，你修改后它实时就切换了。

traefik 也支持动态配置。而且是三者中最成熟的那个。

性能

使用 100 个 WRK 测试 HTTP 代理，在同一机器下，每秒的最大并发数：

可以看到老牌的 Nginx 还是胜出了。不过，这种测试一般意义不大，因为我们的瓶颈主要都在数据库等其他方面。

哦，其实，数据库也不是瓶颈，最大的瓶颈是 网络 。

中间件的实现和生态

也就是一些更详细的功能实现。

比如 身份验证、安全过滤/防火墙、数据头部、限流、CORS、压缩等等。

这边举一个频率限制的例子。看看这三个都是怎么实现的。

# Nginx
http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}


# Traefik
#（这个 Traefik 引入了中间件链的概念，能反复复用，对于复杂配置很友好）
labels:
  - "traefik.http.middlewares.ratelimit.ratelimit.average=10"
  - "traefik.http.middlewares.ratelimit.ratelimit.burst=20"
  - "traefik.http.routers.api.middlewares=ratelimit"


# Caddy（需要安装第三方插件）
api.example.com {
    rate_limit {remote.ip} 10r/s
    reverse_proxy localhost:3000
}

配置复杂度依次递减啊....

在生态方面，Nginx 的第三方生态最好了。当然，一般大部分功能，软件里面都写全够用了。

总结一下

Nginx 还是最稳妥的默认选项，但是配置复杂麻烦。如果你的服务千年不动一次，而且硬件差，就要 Nginx 。

如果你用的 K8S ，或者配置相对复杂，比如 微服务 动不动需要扩容，那就使用 Traefik 。

如果你懒得搞那么多，就用最简单的 Caddy 。

参考资料：

https://www.reddit.com/r/selfhosted/comments/uw50ua/caddydockerproxy_vs_traefik_vs_nginxproxymanager/

https://www.programonaut.com/reverse-proxies-compared-traefik-vs-caddy-vs-nginx-docker/

https://dev.to/instadevops/nginx-vs-traefik-vs-caddy-which-reverse-proxy-should-you-pick-3ekl

阅读原文：原文链接