StripPrefix middleware behavior with chained request transformations

Direct answer

Yes. Traefik executes middlewares strictly in the order they appear in a router’s middleware list. Each middleware receives the request object exactly as it has been altered by all preceding middlewares. Therefore, a StripPrefix middleware sees the path that results from any earlier middleware, and any later middleware (including another StripPrefix) sees the path after the earlier strip has been applied.

Confirmed facts

• When a StripPrefix runs, it removes its configured prefix only if the current request path starts with that prefix; otherwise it leaves the path unchanged and passes the request onward.
• If two StripPrefix middlewares are chained, the final path equals the original path minus the first successfully matched prefix, then minus the second successfully matched prefix applied to the already‑stripped result.
• A later StripPrefix that does not find its prefix at the start of the current path simply forwards the request unchanged; no error is raised.

Likely explanation (behavior you can expect)

Because the request path is mutated in‑place, the ability of a downstream middleware to match against the original URL depends entirely on what has happened upstream. Placing a StripPrefix before a path‑matching middleware (e.g., another StripPrefix, PathPrefix, or a header‑based middleware that inspects the path) causes that downstream middleware to operate on the already‑stripped path. Conversely, reversing the order can prevent a match if the first strip does not apply.

Steps to verify this behavior

1. Define a Traefik router (file provider) that chains two StripPrefix middlewares and points to an echo service that logs the final request path.
2. Example configuration:

http:
  routers:
    test-router:
      rule: Host(`example.com`)
      service: echo-service
      middlewares:
        - strip-api
        - strip-v1
  middlewares:
    strip-api:
      stripPrefix:
        prefixes:
          - /api
    strip-v1:
      stripPrefix:
        prefixes:
          - /v1
  services:
    echo-service:
      loadBalancer:
        servers:
          - url: \"http://echoserver:8080\"

3. Send a request: curl -v http://example.com/api/v1/resource
4. Check the echo service logs. With the order above (strip-api then strip-v1) the logged path should be /resource (both prefixes removed).
5. Reverse the middleware order (strip-v1 then strip-api) and repeat the request. The first strip (strip-v1) does not match (/api/v1/resource does not start with /v1), so the path remains unchanged; the second strip also fails to match (/api is not at the start because the path still begins with /api but the first strip didn’t run, so it now matches and removes /api, leaving /v1/resource). The logged path will be /v1/resource, demonstrating order sensitivity.

What to confirm if the result differs

If you observe behavior that does not match the description above, verify the Traefik version you are running. The ordering guarantees described apply to Traefik v2 (the current stable line). Legacy v1 versions used a different middleware stacking model and may produce different outcomes.