Traefik IP Allowlist: Restrict Access by Source IP (2026)

Traefik’s IP allowlist feature lets you lock down your services, but it’s not about simple firewalling; it’s about fine-grained access control at the edge, letting you delegate IP-based decisions to Traefik itself.

Let’s see Traefik in action with an IP allowlist. Imagine we have a sensitive internal dashboard running behind Traefik, and we only want it accessible from our office’s static IP address (192.0.2.100) and a specific development machine (198.51.100.50).

Here’s a Traefik configuration snippet using dynamic configuration via a file provider (e.g., traefik.yml or a separate dynamic.yml file):

http:
  routers:
    my-dashboard-router:
      rule: "Host(`dashboard.example.com`)"
      service: "my-dashboard-service"
      middlewares:
        - "ip-whitelist-middleware"

  services:
    my-dashboard-service:
      loadBalancer:
        servers:
          - url: "http://10.0.0.5:8080"

  middlewares:
    ip-whitelist-middleware:
      ipWhiteList:
        sourceRange:
          - "192.0.2.100"
          - "198.51.100.50/32"

In this setup:

• my-dashboard-router is configured to match requests for dashboard.example.com.
• It’s attached to the ip-whitelist-middleware.
• my-dashboard-service points to our actual dashboard application running on 10.0.0.5:8080.
• The ip-whitelist-middleware uses the ipWhiteList plugin.
• sourceRange is a list of IP addresses or CIDR blocks that are permitted. We’ve specified the office IP 192.0.2.100 and the dev machine 198.51.100.50/32. The /32 is explicit for a single IP, though often optional for single IPs.

When a request hits Traefik for dashboard.example.com:

1. Traefik matches it to my-dashboard-router.
2. It then evaluates the ip-whitelist-middleware.
3. If the source IP of the incoming request is not in the sourceRange list, Traefik immediately returns a 403 Forbidden response.
4. If the source IP is in the list, the request is allowed to proceed to my-dashboard-service.

This allows you to protect specific routes or even entire applications based on their origin IP address without needing to configure network-level firewalls for each service. The rule in the router determines which requests are subject to the middleware’s IP check.

The power here is that Traefik acts as a central point of access control. You can define multiple routers, each with its own set of IP allowlists, or apply the same allowlist middleware to several routers. For instance, you might have a public API that’s open to everyone, but a private admin interface that’s only accessible from a few specific IPs.

Consider a scenario where Traefik is running behind another proxy or load balancer (e.g., an AWS ELB, an Nginx ingress controller, or even another Traefik instance). In such cases, the X-Forwarded-For header or the X-Real-IP header becomes crucial. Traefik needs to be configured to trust and use these headers to determine the original client IP, not the IP of the immediate proxy.

This is typically handled by Traefik’s trustedProxies configuration. If you don’t configure this, Traefik will use the IP address of the direct connection, which, in a proxied environment, would be the IP of the proxy itself, rendering your IP allowlist ineffective.

Here’s how you’d configure Traefik to trust a specific proxy (e.g., an AWS ELB with the IP range 10.0.0.0/8):

# In Traefik static configuration (traefik.yml or command line args)
entryPoints:
  websecure:
    address: ":443"
    http:
      middlewares:
        - "trusted-proxies-middleware" # Apply this at the entrypoint level

middlewares:
  trusted-proxies-middleware:
    ipWhiteList:
      sourceRange:
        - "10.0.0.0/8" # Example: AWS ELB IP range

This setup tells Traefik: "If you receive a request from an IP within 10.0.0.0/8, assume that the real client IP is whatever is in the X-Forwarded-For header." Traefik then uses that real client IP for its ipWhiteList checks. You can specify multiple CIDR blocks for sourceRange if you have multiple layers of proxies. The order of IPs in X-Forwarded-For matters; Traefik, by default, uses the first IP in the list if trustedProxies is configured.

If you want to restrict access to Traefik itself based on IP address, you can apply the ipWhiteList middleware directly to an entrypoint, as shown in the trusted-proxies-middleware example above, but with your allowed external IPs. This prevents unauthorized access to Traefik’s API or dashboard as well.

The most common pitfall is forgetting to configure trustedProxies when Traefik is not directly exposed to the internet, leading to the allowlist always blocking legitimate traffic from your users or always allowing traffic from the proxy.

Once your IP allowlist is correctly configured, the next challenge is often managing dynamic IP addresses or implementing more sophisticated access control mechanisms like JWT authentication.