Skip to main content

InFlightReq

The InFlightReq middleware proactively prevents services from being overwhelmed with high load.

Configuration Example​

---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-inflightreq
spec:
  inFlightReq:
    sourceCriterion:
      ipStrategy:
        # Use the second IP from the X-Forwarded-For header as clientIP
        depth: 2

Configuration Options​

FieldDescriptionDefaultRequired
amountThe amount option defines the maximum amount of allowed simultaneous in-flight request.
The middleware responds with HTTP 429 Too Many Requests if there are already amount requests in progress (based on the same sourceCriterion strategy).		0No
sourceCriterion.requestHostWhether to consider the request host as the source.
More information about sourceCriterionhere.		falseNo
sourceCriterion.requestHeaderNameName of the header used to group incoming requests.
More information about sourceCriterionhere.		""No
sourceCriterion.ipStrategy.depthDepth position of the IP to select in the X-Forwarded-For header (starting from the right).
0 means no depth.
If greater than the total number of IPs in X-Forwarded-For, then the client IP is empty
If higher than 0, the excludedIPs options is not evaluated.
More information about sourceCriterion, ipStrategy](#ipstrategy), and [depth` below.		0No
sourceCriterion.ipStrategy.excludedIPsAllows Traefik to scan the X-Forwarded-For header and select the first IP not in the list.
If depth is specified, excludedIPs is ignored.
More information about sourceCriterion, ipStrategy](#ipstrategy), and [excludedIPs` below.		No

sourceCriterion​

The sourceCriterion option defines what criterion is used to group requests as originating from a common source. If several strategies are defined at the same time, an error will be raised. If none are set, the default is to use the requestHost.

ipStrategy​

The ipStrategy option defines two parameters that configures how Traefik determines the client IP: depth, and excludedIPs.

As a middleware, InFlightReq happens before the actual proxying to the backend takes place. In addition, the previous network hop only gets appended to X-Forwarded-For during the last stages of proxying, that is after it has already passed through the middleware.
Therefore, during InFlightReq, as the previous network hop is not yet present in X-Forwarded-For, it cannot be used and/or relied upon.

Example of Depth & X-Forwarded-For​

If depth is set to 2, and the request X-Forwarded-For header is "10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1" then the "real" client IP is "10.0.0.1" (at depth 4) but the IP used as the criterion is "12.0.0.1" (depth=2).

X-Forwarded-FordepthclientIP
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1"1"13.0.0.1"
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1"3"11.0.0.1"
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1"5""

Example of ExcludedIPs & X-Forwarded-For​

X-Forwarded-ForexcludedIPsclientIP
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1""12.0.0.1,13.0.0.1""11.0.0.1"
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1""15.0.0.1,13.0.0.1""12.0.0.1"
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1""10.0.0.1,13.0.0.1""12.0.0.1"
"10.0.0.1,11.0.0.1,12.0.0.1,13.0.0.1""15.0.0.1,16.0.0.1""13.0.0.1"
"10.0.0.1,11.0.0.1""10.0.0.1,11.0.0.1"""