Reverse Proxy Patterns for Microservices: Traefik, Nginx, and Caddy Compared

Why Reverse Proxies Matter

In a microservice architecture, clients should never talk directly to backend services. A reverse proxy sits between the internet and your services, handling SSL termination, routing, load balancing, rate limiting, and authentication. It is the single most important piece of your infrastructure.

Pattern 1: Host-Based Routing

Route traffic based on the subdomain:

Traefik (Docker Labels)

services:
  api:
    image: myapp/api:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api.rule=Host(`api.example.com`)"
      - "traefik.http.services.api.loadbalancer.server.port=8080"

  dashboard:
    image: myapp/dashboard:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.dashboard.rule=Host(`app.example.com`)"
      - "traefik.http.services.dashboard.loadbalancer.server.port=3000"

  docs:
    image: myapp/docs:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.docs.rule=Host(`docs.example.com`)"
      - "traefik.http.services.docs.loadbalancer.server.port=80"

Nginx

# /etc/nginx/conf.d/api.conf
server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://api:8080;
        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;
    }
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    location / {
        proxy_pass http://dashboard:3000;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
    }
}

Caddy

api.example.com {
    reverse_proxy api:8080
}

app.example.com {
    reverse_proxy dashboard:3000
}

docs.example.com {
    reverse_proxy docs:80
}

Caddy's simplicity is remarkable — automatic HTTPS, no SSL configuration needed.

Pattern 2: Path-Based Routing

Route based on URL path — useful for monolithic frontends talking to multiple backends:

Traefik

services:
  users-service:
    labels:
      - "traefik.http.routers.users.rule=Host(`api.example.com`) && PathPrefix(`/api/users`)"
      - "traefik.http.middlewares.users-strip.stripprefix.prefixes=/api/users"
      - "traefik.http.routers.users.middlewares=users-strip"

  orders-service:
    labels:
      - "traefik.http.routers.orders.rule=Host(`api.example.com`) && PathPrefix(`/api/orders`)"
      - "traefik.http.middlewares.orders-strip.stripprefix.prefixes=/api/orders"
      - "traefik.http.routers.orders.middlewares=orders-strip"

Nginx

server {
    listen 443 ssl http2;
    server_name api.example.com;

    location /api/users/ {
        rewrite ^/api/users/(.*) /\$1 break;
        proxy_pass http://users-service:8080;
    }

    location /api/orders/ {
        rewrite ^/api/orders/(.*) /\$1 break;
        proxy_pass http://orders-service:8080;
    }

    location /api/payments/ {
        rewrite ^/api/payments/(.*) /\$1 break;
        proxy_pass http://payments-service:8080;
    }
}

Pattern 3: Forward Authentication

Authenticate requests before they reach your services:

Traefik + Authelia

# traefik dynamic config
http:
  middlewares:
    authelia:
      forwardAuth:
        address: "http://authelia:9091/api/authz/forward-auth"
        trustForwardHeader: true
        authResponseHeaders:
          - "Remote-User"
          - "Remote-Groups"
          - "Remote-Email"

Then apply to any service:

services:
  internal-app:
    labels:
      - "traefik.http.routers.internal.middlewares=authelia@file"

Pattern 4: Rate Limiting

Traefik

http:
  middlewares:
    rate-limit:
      rateLimit:
        average: 100
        burst: 50
        period: 1m
        sourceCriterion:
          ipStrategy:
            depth: 1

Nginx

limit_req_zone \$binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }
}

Pattern 5: Load Balancing

Nginx Upstream

upstream api_backend {
    least_conn;  # or round-robin, ip_hash, random
    server api1:8080 weight=3;
    server api2:8080 weight=2;
    server api3:8080 weight=1;
    server api4:8080 backup;

    keepalive 32;
}

Traefik (Docker Replicas)

services:
  api:
    image: myapp/api:latest
    deploy:
      replicas: 3
    labels:
      - "traefik.http.services.api.loadbalancer.server.port=8080"
      - "traefik.http.services.api.loadbalancer.healthcheck.path=/health"
      - "traefik.http.services.api.loadbalancer.healthcheck.interval=10s"

Pattern 6: WebSocket Proxying

# Nginx WebSocket proxy
location /ws/ {
    proxy_pass http://websocket-service:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade \$http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host \$host;
    proxy_read_timeout 3600s;
}

Comparison Table

Which Should You Choose?

• Traefik: Best for Docker-centric setups. Automatic service discovery via labels means you never edit proxy configs when adding services. This is what TechSaaS uses.
• Nginx: Best for raw performance and complex rewrite rules. The most battle-tested option.
• Caddy: Best for simplicity. Automatic HTTPS with zero config. Perfect for small teams.

At TechSaaS, we run Traefik v3 in front of 50+ Docker containers. Adding a new service is as simple as adding Docker labels — no proxy config files to edit, no SSL certificates to manage. Combined with Authelia for SSO, every service gets enterprise-grade authentication and routing automatically.

Questions about reverse proxy architecture? Email us at [email protected].