Services

    The Services are responsible for configuring how to reach the actual services that will eventually handle the incoming requests.

    Declaring an HTTP Service with Two Servers — Using the

    YAML

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.my-service.loadBalancer]
    5.     [[http.services.my-service.loadBalancer.servers]]
    6.       url = "http://<private-ip-server-1>:<private-port-server-1>/"
    7.     [[http.services.my-service.loadBalancer.servers]]
    8.       url = "http://<private-ip-server-2>:<private-port-server-2>/"

    Declaring a TCP Service with Two Servers — Using the File Provider

    YAML

    1. tcp:
    2.   services:
    3.     my-service:
    4.       loadBalancer:
    5.         servers:
    6.         - address: "<private-ip-server-1>:<private-port-server-1>"
    7.         - address: "<private-ip-server-2>:<private-port-server-2>"

    TOML

    1. ## Dynamic configuration
    2. [tcp.services]
    3.   [tcp.services.my-service.loadBalancer]
    4.      [[tcp.services.my-service.loadBalancer.servers]]
    5.        address = "<private-ip-server-1>:<private-port-server-1>"
    6.      [[tcp.services.my-service.loadBalancer.servers]]
    7.        address = "<private-ip-server-2>:<private-port-server-2>"

    Declaring a UDP Service with Two Servers — Using the

    YAML

    1. udp:
    2.   services:
    3.     my-service:
    4.       loadBalancer:
    5.         servers:
    6.         - address: "<private-ip-server-1>:<private-port-server-1>"
    7.         - address: "<private-ip-server-2>:<private-port-server-2>"

    TOML

    1. ## Dynamic configuration
    2. [udp.services]
    3.   [udp.services.my-service.loadBalancer]
    4.      [[udp.services.my-service.loadBalancer.servers]]
    5.        address = "<private-ip-server-1>:<private-port-server-1>"
    6.      [[udp.services.my-service.loadBalancer.servers]]
    7.        address = "<private-ip-server-2>:<private-port-server-2>"

    The load balancers are able to load balance the requests between multiple instances of your programs.

    Each service has a load-balancer, even if there is only one server to forward traffic to.

    Declaring a Service with Two Servers (with Load Balancing) — Using the File Provider

    YAML

    1. http:
    2.   services:
    3.     my-service:
    4.       loadBalancer:
    5.         servers:
    6.         - url: "http://private-ip-server-1/"
    7.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.my-service.loadBalancer]
    5.     [[http.services.my-service.loadBalancer.servers]]
    6.       url = "http://private-ip-server-1/"
    7.     [[http.services.my-service.loadBalancer.servers]]
    8.       url = "http://private-ip-server-2/"

    Servers

    Servers declare a single instance of your program. The url option point to a specific instance.

    Paths in the servers’ url have no effect. If you want the requests to be sent to a specific path on your servers, configure your routers to use a corresponding (e.g. the AddPrefix or ) middlewares.

    A Service with One Server — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         servers:
    7.           - url: "http://private-ip-server-1/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.my-service.loadBalancer]
    4.     [[http.services.my-service.loadBalancer.servers]]
    5.       url = "http://private-ip-server-1/"

    Load-balancing

    For now, only round robin load balancing is supported:

    Load Balancing — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         servers:
    7.         - url: "http://private-ip-server-1/"
    8.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.my-service.loadBalancer]
    4.     [[http.services.my-service.loadBalancer.servers]]
    5.       url = "http://private-ip-server-1/"
    6.     [[http.services.my-service.loadBalancer.servers]]
    7.       url = "http://private-ip-server-2/"

    Sticky sessions

    When sticky sessions are enabled, a Set-Cookie header is set on the initial response to let the client know which server handles the first response. On subsequent requests, to keep the session alive with the same server, the client should send the cookie with the value set.

    Stickiness on multiple levels

    When chaining or mixing load-balancers (e.g. a load-balancer of servers is one of the “children” of a load-balancer of services), for stickiness to work all the way, the option needs to be specified at all required levels. Which means the client needs to send a cookie with as many key/value pairs as there are sticky levels.

    Stickiness & Unhealthy Servers

    If the server specified in the cookie becomes unhealthy, the request will be forwarded to a new server (and the cookie will keep track of the new server).

    Cookie Name

    The default cookie name is an abbreviation of a sha1 (ex: _1d52e).

    Secure & HTTPOnly & SameSite flags

    By default, the affinity cookie is created without those flags. One however can change that through configuration.

    SameSite can be none, lax, strict or empty.

    Adding Stickiness — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         sticky:
    7.          cookie: {}

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.my-service]
    4.     [http.services.my-service.loadBalancer.sticky.cookie]

    Adding Stickiness with custom Options — Using the

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         sticky:
    7.           cookie:
    8.             name: my_sticky_cookie_name
    9.             secure: true
    10.             httpOnly: true

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.my-service]
    4.     [http.services.my-service.loadBalancer.sticky.cookie]
    5.       name = "my_sticky_cookie_name"
    6.       secure = true
    7.       httpOnly = true
    8.       sameSite = "none"

    Setting Stickiness on all the required levels — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     wrr1:
    5.       weighted:
    6.         sticky:
    7.           cookie:
    8.             name: lvl1
    9.         services:
    10.           - name: whoami1
    11.             weight: 1
    12.           - name: whoami2
    13.             weight: 1
    15.     whoami1:
    16.       loadBalancer:
    17.         sticky:
    18.           cookie:
    19.             name: lvl2
    20.         servers:
    21.           - url: http://127.0.0.1:8081
    22.           - url: http://127.0.0.1:8082
    24.     whoami2:
    25.       loadBalancer:
    26.         sticky:
    27.           cookie:
    28.             name: lvl2
    29.         servers:
    30.           - url: http://127.0.0.1:8083
    31.           - url: http://127.0.0.1:8084

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.wrr1]
    4.     [http.services.wrr1.weighted.sticky.cookie]
    5.       name = "lvl1"
    6.     [[http.services.wrr1.weighted.services]]
    7.       name = "whoami1"
    8.       weight = 1
    9.     [[http.services.wrr1.weighted.services]]
    10.       name = "whoami2"
    11.       weight = 1
    13.   [http.services.whoami1]
    14.     [http.services.whoami1.loadBalancer]
    15.       [http.services.whoami1.loadBalancer.sticky.cookie]
    16.         name = "lvl2"
    17.       [[http.services.whoami1.loadBalancer.servers]]
    18.         url = "http://127.0.0.1:8081"
    19.       [[http.services.whoami1.loadBalancer.servers]]
    20.         url = "http://127.0.0.1:8082"
    22.   [http.services.whoami2]
    23.     [http.services.whoami2.loadBalancer]
    24.       [http.services.whoami2.loadBalancer.sticky.cookie]
    25.         name = "lvl2"
    26.       [[http.services.whoami2.loadBalancer.servers]]
    27.         url = "http://127.0.0.1:8083"
    28.       [[http.services.whoami2.loadBalancer.servers]]
    29.         url = "http://127.0.0.1:8084"

    To keep a session open with the same server, the client would then need to specify the two levels within the cookie for each request, e.g. with curl:

    1. curl -b "lvl1=whoami1; lvl2=http://127.0.0.1:8081" http://localhost:8000

    Health Check

    Configure health check to remove unhealthy servers from the load balancing rotation. Traefik will consider your servers healthy as long as they return status codes between 2XX and 3XX to the health check requests (carried out every interval).

    To propagate status changes (e.g. all servers of this service are down) upwards, HealthCheck must also be enabled on the parent(s) of this service.

    Below are the available options for the health check mechanism:

    • path (required), defines the server URL path for the health check endpoint .
    • scheme (optional), replaces the server URL scheme for the health check endpoint.
    • hostname (optional), sets the value of hostname in the Host header of the health check request.
    • port (optional), replaces the server URL port for the health check endpoint.
    • interval (default: 30s), defines the frequency of the health check calls.
    • timeout (default: 5s), defines the maximum duration Traefik will wait for a health check request before considering the server unhealthy.
    • headers (optional), defines custom headers to be sent to the health check endpoint.
    • followRedirects (default: true), defines whether redirects should be followed during the health check calls.
    • method (default: GET), defines the HTTP method that will be used while connecting to the endpoint.

    Interval & Timeout Format

    Interval and timeout are to be given in a format understood by time.ParseDuration. The interval must be greater than the timeout. If configuration doesn’t reflect this, the interval will be set to timeout + 1 second.

    Recovering Servers

    Traefik keeps monitoring the health of unhealthy servers. If a server has recovered (returning 2xx -> 3xx responses again), it will be added back to the load balancer rotation pool.

    Health check with Kubernetes

    Kubernetes has an health check mechanism to remove unhealthy pods from Kubernetes services (cf ). As unhealthy pods have no Kubernetes endpoints, Traefik will not forward traffic to them. Therefore, Traefik health check is not available for kubernetesCRD and kubernetesIngress providers.

    Custom Interval & Timeout — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service-1:
    5.       loadBalancer:
    6.         healthCheck:
    7.           path: /health
    8.           interval: "10s"
    9.           timeout: "3s"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.Service-1]
    4.     [http.services.Service-1.loadBalancer.healthCheck]
    5.       path = "/health"
    6.       interval = "10s"
    7.       timeout = "3s"

    Custom Port — Using the

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service-1:
    5.       loadBalancer:
    6.         healthCheck:
    7.           path: /health
    8.           port: 8080

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.Service-1]
    4.     [http.services.Service-1.loadBalancer.healthCheck]
    5.       path = "/health"
    6.       port = 8080

    Custom Scheme — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service-1:
    5.       loadBalancer:
    6.         healthCheck:
    7.           path: /health
    8.           scheme: http

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.Service-1]
    4.     [http.services.Service-1.loadBalancer.healthCheck]
    5.       path = "/health"
    6.       scheme = "http"

    Additional HTTP Headers — Using the

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service-1:
    5.       loadBalancer:
    6.         healthCheck:
    7.           path: /health
    8.           headers:
    9.             My-Custom-Header: foo
    10.             My-Header: bar

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.Service-1]
    4.     [http.services.Service-1.loadBalancer.healthCheck]
    5.       path = "/health"
    7.       [http.services.Service-1.loadBalancer.healthCheck.headers]
    8.         My-Custom-Header = "foo"
    9.         My-Header = "bar"

    Pass Host Header

    The passHostHeader allows to forward client Host header to server.

    By default, passHostHeader is true.

    Don’t forward the host header — Using the

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service01:
    5.       loadBalancer:
    6.         passHostHeader: false

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.Service01]
    4.     [http.services.Service01.loadBalancer]
    5.       passHostHeader = false

    ServersTransport

    serversTransport allows to reference a configuration for the communication between Traefik and your servers.

    Specify a transport — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service01:
    5.       loadBalancer:
    6.         serversTransport: mytransport
    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.Service01]
    4.     [http.services.Service01.loadBalancer]
    5.       serversTransport = "mytransport"

    Info

    If no serversTransport is specified, the [[email protected]](https://doc.traefik.io/cdn-cgi/l/email-protection) will be used. The [[email protected]](https://doc.traefik.io/cdn-cgi/l/email-protection) serversTransport is created from the .

    Response Forwarding

    This section is about configuring how Traefik forwards the response from the backend server to the client.

    Below are the available options for the Response Forwarding mechanism:

    • FlushInterval specifies the interval in between flushes to the client while copying the response body. It is a duration in milliseconds, defaulting to 100. A negative value means to flush immediately after each write to the client. The FlushInterval is ignored when ReverseProxy recognizes a response as a streaming response; for such responses, writes are flushed to the client immediately.

    Using a custom FlushInterval — Using the

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     Service-1:
    5.       loadBalancer:
    6.         responseForwarding:
    7.           flushInterval: 1s

    TOML

    ServersTransport

    ServersTransport allows to configure the transport between Traefik and your servers.

    ServerName

    Optional

    serverName configure the server name that will be used for SNI.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       serverName: "myhost"

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport]

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     serverName: "test"

    Certificates

    Optional

    certificates is the list of certificates (as file paths, or data bytes) that will be set as client certificates for mTLS.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    4.     mytransport:
    5.       certificates:
    6.         - certFile: foo.crt
    7.           keyFile: bar.crt

    File (TOML)

    1. ## Dynamic configuration
    2. [[http.serversTransports.mytransport.certificates]]
    3.   certFile = "foo.crt"
    4.   keyFile = "bar.crt"

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     certificatesSecrets:
    9.     - mycert
    11. ---
    12. apiVersion: v1
    13. kind: Secret
    14. metadata:
    15.   name: mycert
    17.   data:
    18.     tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=
    19.     tls.key: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0=

    insecureSkipVerify

    Optional

    insecureSkipVerify controls whether the server’s certificate chain and host name is verified.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       insecureSkipVerify: true

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport]
    3.   insecureSkipVerify = true

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     insecureSkipVerify: true

    rootCAs

    Optional

    rootCAs defines the set of root certificate authorities (as file paths, or data bytes) to use when verifying server certificates.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       rootCAs:
    6.         - foo.crt
    7.         - bar.crt

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport]
    3.   rootCAs = ["foo.crt", "bar.crt"]

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     rootCAsSecrets:
    9.     - myca
    10. ---
    11. apiVersion: v1
    12. kind: Secret
    13. metadata:
    14.   name: myca
    16.   data:
    17.     ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=

    maxIdleConnsPerHost

    Optional, Default=2

    If non-zero, maxIdleConnsPerHost controls the maximum idle (keep-alive) connections to keep per-host.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       maxIdleConnsPerHost: 7

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport]
    3.   maxIdleConnsPerHost = 7

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     maxIdleConnsPerHost: 7

    disableHTTP2

    Optional, Default=false

    disableHTTP2 disables HTTP/2 for connections with servers.

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport]
    3.   disableHTTP2 = true

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       disableHTTP2: true

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     disableHTTP2: true

    peerCertURI

    Optional, Default=false

    peerCertURI defines the URI used to match against SAN URIs during the server’s certificate verification.

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport]
    3.   peerCertURI = "foobar"

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       peerCertURI: foobar

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     peerCertURI: foobar

    forwardingTimeouts

    forwardingTimeouts are the timeouts applied when forwarding requests to the servers.

    forwardingTimeouts.dialTimeout

    Optional, Default=30s

    dialTimeout is the maximum duration allowed for a connection to a backend server to be established. Zero means no timeout.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       forwardingTimeouts:
    6.         dialTimeout: "1s"

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport.forwardingTimeouts]
    3.   dialTimeout = "1s"

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     forwardingTimeouts:
    9.       dialTimeout: "1s"
    forwardingTimeouts.responseHeaderTimeout

    Optional, Default=0s

    responseHeaderTimeout, if non-zero, specifies the amount of time to wait for a server’s response headers after fully writing the request (including its body, if any). This time does not include the time to read the response body. Zero means no timeout.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       forwardingTimeouts:
    6.         responseHeaderTimeout: "1s"

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport.forwardingTimeouts]
    3.   responseHeaderTimeout = "1s"

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     forwardingTimeouts:
    9.       responseHeaderTimeout: "1s"
    forwardingTimeouts.idleConnTimeout

    Optional, Default=90s

    idleConnTimeout is the maximum amount of time an idle (keep-alive) connection will remain idle before closing itself. Zero means no limit.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       forwardingTimeouts:
    6.         idleConnTimeout: "1s"

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport.forwardingTimeouts]
    3.   idleConnTimeout = "1s"

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     forwardingTimeouts:
    9.       idleConnTimeout: "1s"
    forwardingTimeouts.readIdleTimeout

    Optional, Default=0s

    readIdleTimeout is the timeout after which a health check using ping frame will be carried out if no frame is received on the HTTP/2 connection. Note that a ping response will be considered a received frame, so if there is no other traffic on the connection, the health check will be performed every readIdleTimeout interval. If zero, no health check is performed.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       forwardingTimeouts:
    6.         readIdleTimeout: "1s"

    File (TOML)

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     forwardingTimeouts:
    9.       readIdleTimeout: "1s"
    forwardingTimeouts.pingTimeout

    Optional, Default=15s

    pingTimeout is the timeout after which the HTTP/2 connection will be closed if a response to ping is not received.

    File (YAML)

    1. ## Dynamic configuration
    2. http:
    3.   serversTransports:
    4.     mytransport:
    5.       forwardingTimeouts:
    6.         pingTimeout: "1s"

    File (TOML)

    1. ## Dynamic configuration
    2. [http.serversTransports.mytransport.forwardingTimeouts]
    3.   pingTimeout = "1s"

    Kubernetes

    1. apiVersion: traefik.io/v1alpha1
    2. kind: ServersTransport
    3. metadata:
    4.   name: mytransport
    5.   namespace: default
    7. spec:
    8.     forwardingTimeouts:
    9.       pingTimeout: "1s"

    Weighted Round Robin (service)

    The WRR is able to load balance the requests between multiple services based on weights.

    This strategy is only available to load balance between and not between servers.

    Supported Providers

    This strategy can be defined currently with the or IngressRoute providers.

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     app:
    5.       weighted:
    6.         services:
    7.         - name: appv1
    8.           weight: 3
    9.         - name: appv2
    10.           weight: 1
    12.     appv1:
    13.       loadBalancer:
    14.         servers:
    15.         - url: "http://private-ip-server-1/"
    17.     appv2:
    18.       loadBalancer:
    19.         servers:
    20.         - url: "http://private-ip-server-2/"
    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.app]
    4.     [[http.services.app.weighted.services]]
    5.       name = "appv1"
    6.       weight = 3
    7.     [[http.services.app.weighted.services]]
    8.       name = "appv2"
    9.       weight = 1
    11.   [http.services.appv1]
    12.     [http.services.appv1.loadBalancer]
    13.       [[http.services.appv1.loadBalancer.servers]]
    14.         url = "http://private-ip-server-1/"
    16.   [http.services.appv2]
    17.     [http.services.appv2.loadBalancer]
    18.       [[http.services.appv2.loadBalancer.servers]]
    19.         url = "http://private-ip-server-2/"

    Health Check

    HealthCheck enables automatic self-healthcheck for this service, i.e. whenever one of its children is reported as down, this service becomes aware of it, and takes it into account (i.e. it ignores the down child) when running the load-balancing algorithm. In addition, if the parent of this service also has HealthCheck enabled, this service reports to its parent any status change.

    All or nothing

    If HealthCheck is enabled for a given service, but any of its descendants does not have it enabled, the creation of the service will fail.

    HealthCheck on Weighted services can be defined currently only with the File provider.

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     app:
    5.       weighted:
    6.         healthCheck: {}
    7.         services:
    8.         - name: appv1
    9.           weight: 3
    10.         - name: appv2
    11.           weight: 1
    13.     appv1:
    14.       loadBalancer:
    15.         healthCheck:
    16.           path: /status
    17.           interval: 10s
    18.           timeout: 3s
    19.         servers:
    20.         - url: "http://private-ip-server-1/"
    22.     appv2:
    23.       loadBalancer:
    24.         healthCheck:
    25.           path: /status
    26.           interval: 10s
    27.           timeout: 3s
    28.         servers:
    29.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.app]
    4.     [http.services.app.weighted.healthCheck]
    5.     [[http.services.app.weighted.services]]
    6.       name = "appv1"
    7.       weight = 3
    8.     [[http.services.app.weighted.services]]
    9.       name = "appv2"
    10.       weight = 1
    12.   [http.services.appv1]
    13.     [http.services.appv1.loadBalancer]
    14.       [http.services.appv1.loadBalancer.healthCheck]
    15.         path = "/health"
    16.         interval = "10s"
    17.         timeout = "3s"
    18.       [[http.services.appv1.loadBalancer.servers]]
    19.         url = "http://private-ip-server-1/"
    21.   [http.services.appv2]
    22.     [http.services.appv2.loadBalancer]
    23.       [http.services.appv2.loadBalancer.healthCheck]
    24.         path = "/health"
    25.         interval = "10s"
    26.         timeout = "3s"
    27.       [[http.services.appv2.loadBalancer.servers]]
    28.         url = "http://private-ip-server-2/"

    The mirroring is able to mirror requests sent to a service to other services. Please note that by default the whole request is buffered in memory while it is being mirrored. See the maxBodySize option in the example below for how to modify this behaviour.

    Supported Providers

    This strategy can be defined currently with the File or providers.

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     mirrored-api:
    5.       mirroring:
    7.         # maxBodySize is the maximum size allowed for the body of the request.
    8.         # Default value is -1, which means unlimited size.
    9.         maxBodySize: 1024
    10.         mirrors:
    11.         - name: appv2
    12.           percent: 10
    14.     appv1:
    15.       loadBalancer:
    16.         servers:
    17.         - url: "http://private-ip-server-1/"
    19.     appv2:
    20.       loadBalancer:
    21.         servers:
    22.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.mirrored-api]
    4.     [http.services.mirrored-api.mirroring]
    5.       service = "appv1"
    6.       # maxBodySize is the maximum size in bytes allowed for the body of the request.
    7.       # If the body is larger, the request is not mirrored.
    8.       # Default value is -1, which means unlimited size.
    9.       maxBodySize = 1024
    10.     [[http.services.mirrored-api.mirroring.mirrors]]
    11.       name = "appv2"
    12.       percent = 10
    14.   [http.services.appv1]
    15.     [http.services.appv1.loadBalancer]
    16.       [[http.services.appv1.loadBalancer.servers]]
    17.         url = "http://private-ip-server-1/"
    19.   [http.services.appv2]
    20.     [http.services.appv2.loadBalancer]
    21.       [[http.services.appv2.loadBalancer.servers]]
    22.         url = "http://private-ip-server-2/"

    Health Check

    HealthCheck enables automatic self-healthcheck for this service, i.e. if the main handler of the service becomes unreachable, the information is propagated upwards to its parent.

    All or nothing

    If HealthCheck is enabled for a given service, but any of its descendants does not have it enabled, the creation of the service will fail.

    HealthCheck on Mirroring services can be defined currently only with the provider.

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     mirrored-api:
    5.       mirroring:
    6.         healthCheck: {}
    7.         service: appv1
    8.         mirrors:
    9.         - name: appv2
    10.           percent: 10
    12.     appv1:
    13.       loadBalancer:
    14.         healthCheck:
    15.           path: /status
    16.           interval: 10s
    17.           timeout: 3s
    18.         servers:
    19.         - url: "http://private-ip-server-1/"
    21.     appv2:
    22.       loadBalancer:
    23.         servers:
    24.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.mirrored-api]
    4.     [http.services.mirrored-api.mirroring]
    5.       [http.services.mirrored-api.mirroring.healthCheck]
    6.       service = "appv1"
    7.     [[http.services.mirrored-api.mirroring.mirrors]]
    8.       name = "appv2"
    9.       percent = 10
    11.   [http.services.appv1]
    12.     [http.services.appv1.loadBalancer]
    13.       [http.services.appv1.loadBalancer.healthCheck]
    14.         path = "/health"
    15.         interval = "10s"
    16.         timeout = "3s"
    17.       [[http.services.appv1.loadBalancer.servers]]
    18.         url = "http://private-ip-server-1/"
    20.   [http.services.appv2]
    21.     [http.services.appv2.loadBalancer]
    22.       [http.services.appv1.loadBalancer.healthCheck]
    23.         path = "/health"
    24.         interval = "10s"
    25.         timeout = "3s"
    26.       [[http.services.appv2.loadBalancer.servers]]
    27.         url = "http://private-ip-server-2/"

    Failover (service)

    A failover service job is to forward all requests to a fallback service when the main service becomes unreachable.

    Relation to HealthCheck

    The failover service relies on the HealthCheck system to get notified when its main service becomes unreachable, which means HealthCheck needs to be enabled and functional on the main service. However, HealthCheck does not need to be enabled on the failover service itself for it to be functional. It is only required in order to propagate upwards the information when the failover itself becomes down (i.e. both its main and its fallback are down too).

    Supported Providers

    This strategy can currently only be defined with the provider.

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     app:
    5.       failover:
    6.         service: main
    7.         fallback: backup
    9.     main:
    10.       loadBalancer:
    11.         healthCheck:
    12.           path: /status
    13.           interval: 10s
    14.           timeout: 3s
    15.         servers:
    16.         - url: "http://private-ip-server-1/"
    18.     backup:
    19.       loadBalancer:
    20.         servers:
    21.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.app]
    4.     [http.services.app.failover]
    5.       service = "main"
    6.       fallback = "backup"
    8.   [http.services.main]
    9.     [http.services.main.loadBalancer]
    10.       [http.services.main.loadBalancer.healthCheck]
    11.         path = "/health"
    12.         interval = "10s"
    13.         timeout = "3s"
    14.       [[http.services.main.loadBalancer.servers]]
    15.         url = "http://private-ip-server-1/"
    17.   [http.services.backup]
    18.     [http.services.backup.loadBalancer]
    19.       [[http.services.backup.loadBalancer.servers]]
    20.         url = "http://private-ip-server-2/"

    Health Check

    HealthCheck enables automatic self-healthcheck for this service, i.e. if the main and the fallback services become unreachable, the information is propagated upwards to its parent.

    All or nothing

    If HealthCheck is enabled for a given service, but any of its descendants does not have it enabled, the creation of the service will fail.

    HealthCheck on a Failover service can currently only be defined with the provider.

    YAML

    1. ## Dynamic configuration
    2. http:
    3.   services:
    4.     app:
    5.       failover:
    6.         healthCheck: {}
    7.         service: main
    8.         fallback: backup
    10.     main:
    11.       loadBalancer:
    12.         healthCheck:
    13.           path: /status
    14.           interval: 10s
    15.           timeout: 3s
    16.         servers:
    17.         - url: "http://private-ip-server-1/"
    19.     backup:
    20.       loadBalancer:
    21.         healthCheck:
    22.           path: /status
    23.           interval: 10s
    24.           timeout: 3s
    25.         servers:
    26.         - url: "http://private-ip-server-2/"

    TOML

    1. ## Dynamic configuration
    2. [http.services]
    3.   [http.services.app]
    4.     [http.services.app.failover.healthCheck]
    5.     [http.services.app.failover]
    6.       service = "main"
    7.       fallback = "backup"
    9.   [http.services.main]
    10.     [http.services.main.loadBalancer]
    11.       [http.services.main.loadBalancer.healthCheck]
    12.         path = "/health"
    13.         interval = "10s"
    14.         timeout = "3s"
    15.       [[http.services.main.loadBalancer.servers]]
    16.         url = "http://private-ip-server-1/"
    18.   [http.services.backup]
    19.     [http.services.backup.loadBalancer]
    20.       [http.services.backup.loadBalancer.healthCheck]
    21.         path = "/health"
    22.         interval = "10s"
    23.         timeout = "3s"
    24.       [[http.services.backup.loadBalancer.servers]]
    25.         url = "http://private-ip-server-2/"

    General

    Each of the fields of the service section represents a kind of service. Which means, that for each specified service, one of the fields, and only one, has to be enabled to define what kind of service is created. Currently, the two available kinds are LoadBalancer, and Weighted.

    The servers load balancer is in charge of balancing the requests between the servers of the same service.

    Declaring a Service with Two Servers — Using the

    YAML

    1. ## Dynamic configuration
    2. tcp:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         servers:
    7.         - address: "xx.xx.xx.xx:xx"
    8.         - address: "xx.xx.xx.xx:xx"

    TOML

    1. ## Dynamic configuration
    2. [tcp.services]
    3.   [tcp.services.my-service.loadBalancer]
    4.     [[tcp.services.my-service.loadBalancer.servers]]
    5.       address = "xx.xx.xx.xx:xx"
    6.     [[tcp.services.my-service.loadBalancer.servers]]
    7.        address = "xx.xx.xx.xx:xx"

    Servers

    Servers declare a single instance of your program. The address option (IP:Port) point to a specific instance.

    A Service with One Server — Using the

    YAML

    1. ## Dynamic configuration
    2. tcp:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         servers:
    7.           - address: "xx.xx.xx.xx:xx"

    TOML

    1. ## Dynamic configuration
    2. [tcp.services]
    3.   [tcp.services.my-service.loadBalancer]
    4.     [[tcp.services.my-service.loadBalancer.servers]]
    5.       address = "xx.xx.xx.xx:xx"

    PROXY Protocol

    Traefik supports version 1 and 2 on TCP Services. It can be enabled by setting proxyProtocol on the load balancer.

    Below are the available options for the PROXY protocol:

    • version specifies the version of the protocol to be used. Either 1 or 2.

    Version

    Specifying a version is optional. By default the version 2 will be used.

    A Service with Proxy Protocol v1 — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. tcp:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         proxyProtocol:
    7.           version: 1

    TOML

    1. ## Dynamic configuration
    2. [tcp.services]
    3.   [tcp.services.my-service.loadBalancer]
    4.     [tcp.services.my-service.loadBalancer.proxyProtocol]
    5.       version = 1

    Termination Delay

    As a proxy between a client and a server, it can happen that either side (e.g. client side) decides to terminate its writing capability on the connection (i.e. issuance of a FIN packet). The proxy needs to propagate that intent to the other side, and so when that happens, it also does the same on its connection with the other side (e.g. backend side).

    However, if for some reason (bad implementation, or malicious intent) the other side does not eventually do the same as well, the connection would stay half-open, which would lock resources for however long.

    To that end, as soon as the proxy enters this termination sequence, it sets a deadline on fully terminating the connections on both sides.

    The termination delay controls that deadline. It is a duration in milliseconds, defaulting to 100. A negative value means an infinite deadline (i.e. the connection is never fully terminated by the proxy itself).

    A Service with a termination delay — Using the File Provider

    YAML

    1. ## Dynamic configuration
    2. tcp:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         terminationDelay: 200

    TOML

    1. ## Dynamic configuration
    2. [tcp.services]
    3.   [tcp.services.my-service.loadBalancer]
    4.     [[tcp.services.my-service.loadBalancer]]
    5.       terminationDelay = 200

    Weighted Round Robin

    The Weighted Round Robin (alias WRR) load-balancer of services is in charge of balancing the requests between multiple services based on provided weights.

    This strategy is only available to load balance between services and not between .

    Supported Providers

    This strategy can be defined currently with the File or providers.

    YAML

    1. ## Dynamic configuration
    2. tcp:
    3.   services:
    4.     app:
    5.       weighted:
    6.         services:
    7.         - name: appv1
    8.           weight: 3
    9.         - name: appv2
    10.           weight: 1
    12.     appv1:
    13.       loadBalancer:
    14.         servers:
    15.         - address: "xxx.xxx.xxx.xxx:8080"
    17.     appv2:
    18.       loadBalancer:
    19.         servers:
    20.         - address: "xxx.xxx.xxx.xxx:8080"

    TOML

    1. ## Dynamic configuration
    2. [tcp.services]
    3.   [tcp.services.app]
    4.     [[tcp.services.app.weighted.services]]
    5.       name = "appv1"
    6.       weight = 3
    7.     [[tcp.services.app.weighted.services]]
    8.       name = "appv2"
    9.       weight = 1
    11.   [tcp.services.appv1]
    12.     [tcp.services.appv1.loadBalancer]
    13.       [[tcp.services.appv1.loadBalancer.servers]]
    14.         address = "private-ip-server-1:8080/"
    16.   [tcp.services.appv2]
    17.     [tcp.services.appv2.loadBalancer]
    18.       [[tcp.services.appv2.loadBalancer.servers]]
    19.         address = "private-ip-server-2:8080/"

    General

    Each of the fields of the service section represents a kind of service. Which means, that for each specified service, one of the fields, and only one, has to be enabled to define what kind of service is created. Currently, the two available kinds are LoadBalancer, and Weighted.

    The servers load balancer is in charge of balancing the requests between the servers of the same service.

    Declaring a Service with Two Servers — Using the

    YAML

    1. ## Dynamic configuration
    2. udp:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         servers:
    7.         - address: "xx.xx.xx.xx:xx"
    8.         - address: "xx.xx.xx.xx:xx"

    TOML

    1. ## Dynamic configuration
    2. [udp.services]
    3.   [udp.services.my-service.loadBalancer]
    4.     [[udp.services.my-service.loadBalancer.servers]]
    5.       address = "xx.xx.xx.xx:xx"
    6.     [[udp.services.my-service.loadBalancer.servers]]
    7.       address = "xx.xx.xx.xx:xx"

    Servers

    The Servers field defines all the servers that are part of this load-balancing group, i.e. each address (IP:Port) on which an instance of the service’s program is deployed.

    A Service with One Server — Using the

    YAML

    1. ## Dynamic configuration
    2. udp:
    3.   services:
    4.     my-service:
    5.       loadBalancer:
    6.         servers:
    7.           - address: "xx.xx.xx.xx:xx"

    TOML

    1. ## Dynamic configuration
    2. [udp.services]
    3.   [udp.services.my-service.loadBalancer]
    4.     [[udp.services.my-service.loadBalancer.servers]]
    5.       address = "xx.xx.xx.xx:xx"

    Weighted Round Robin

    The Weighted Round Robin (alias WRR) load-balancer of services is in charge of balancing the requests between multiple services based on provided weights.

    This strategy is only available to load balance between and not between servers.

    This strategy can only be defined with .

    YAML

    1. ## Dynamic configuration
    2. udp:
    3.   services:
    4.     app:
    5.       weighted:
    6.         services:
    7.         - name: appv1
    8.           weight: 3
    9.         - name: appv2
    10.           weight: 1
    12.     appv1:
    13.       loadBalancer:
    14.         servers:
    15.         - address: "xxx.xxx.xxx.xxx:8080"
    17.     appv2:
    18.       loadBalancer:
    19.         servers:
    20.         - address: "xxx.xxx.xxx.xxx:8080"

    TOML

    Using Traefik for Business Applications?

    Traefik Enterprise simplifies the discovery, security, and deployment of APIs and microservices across any environment. See it in action in this short video walkthrough.