About the Middleware Order that Traefik apply

mattvasc-opus · August 20, 2021, 4:54pm

Hi guys, I did open this Github Issue:

github.com/traefik/traefik

Issue regarding the Middleware Order

opened 03:47PM - 20 Aug 21 UTC

closed 03:52PM - 20 Aug 21 UTC

mattvasc-mcd

kind/question

### Welcome! - [X] Yes, I've searched similar issues on [GitHub](https://github….com/traefik/traefik/issues) and didn't find any. - [X] Yes, I've searched similar issues on the [Traefik community forum](https://community.containo.us) and didn't find any. ### What did you do? Hi guys, sup? I'm running Traefik with a service that has two instances, and using three middlewares: - path-strip, - retry - circuitbreaker My idea is to use the retry middleware before the circuitbreaker to redirect to the other instance, if the one that the Traefik target at the moment (due round robin) is off. But I get different results according to the order of the middleware are defined. ### What did you see instead? Assuming that I kill one instance, leaving only the other one instance running. If I define the middleware's list on the following order: - response-check - test-retry - path-strip The circuit breaker will never enter on the open state, but if I define in the order: - test-retry - response-check - path-strip The circuit breaker will always get triggered. Shouldn't the retry middleware take precedence over the circuitbreaker? Or the Traefik evaluates the middlewares in the backwards direction? I got the same behavior using the chain middleware. (That was asked here https://github.com/traefik/traefik/issues/8218) ### What version of Traefik are you using? Running traefik on bare metal (Windows 10), version 2.4.13. ### What is your environment & configuration? the configuration file (traefik.yml): ```yaml providers: file: directory: "C:/service_routes" watch: true entryPoints: web: address: ":8999" traefik: address: ":9000" api: insecure: true dashboard: true debug: true ``` The only service configuration file (service1.yml) ```yaml http: routers: router0: entryPoints: - web middlewares: - response-check - test-retry - path-strip service: service-foo rule: Path(`/foo`) middlewares: chain-midleware: chain: middlewares: - response-check - test-retry - path-strip path-strip: stripprefix: prefixes: /foo response-check: circuitbreaker: expression: ResponseCodeRatio(500, 600, 0, 600) > 0.1 test-retry: retry: attempts: 2 services: service-foo: loadBalancer: servers: - url: http://127.0.0.1:9001 - url: http://127.0.0.1:9002 passHostHeader: false ``` ### If applicable, please paste the log output in DEBUG level N.A.

But it was marked as a configuration issue.

I'm not sure if it is the case, since I do know how to do a workaround to get things working, but the "strange" behavior is still there.

Does traefik evaluate the middlewares on the backwards direction?

Topic		Replies	Views
Retry middleware not working Traefik v2 middleware	0	69	December 12, 2024
Anyone Else Struggle with Middleware Order in Traefik v3? Traefik v3 (latest) middleware	1	22	April 12, 2025
Traefik infront "sleeping" cloud run retry middleware Traefik v2 middleware	0	336	January 26, 2022
Circuit Breaker Backend issue Traefik v1 service-fabric	2	754	August 1, 2019
Grpc circuit breaker Traefik v2 middleware	1	531	February 3, 2020

About the Middleware Order that Traefik apply

Related topics