Explain the internal working of ServersTransport in Traefik?

ServersTransport configures the HTTP client Traefik uses internally when it connects to a backend server, as opposed to the router/entrypoint settings that govern the client-facing side of the connection.

http:
  serversTransports:
    mytransport:
      serverName: backend.internal
      insecureSkipVerify: false
      rootCAs:
        - /certs/backend-ca.pem
      certificates:
        - certFile: /certs/client.crt
          keyFile: /certs/client.key

It governs things like whether Traefik verifies the backend's TLS certificate, which CA bundle to trust for that verification, what client certificate to present (for backend-side mTLS), connection and response header timeouts, and the maximum idle connections kept open per backend host.

A service references a named ServersTransport, and internally Traefik maintains a separate pooled HTTP transport (connection pool) per distinct ServersTransport configuration, reusing TCP connections to the same backend across requests rather than establishing a fresh TLS handshake every time, which is a meaningful latency and CPU cost saving under load.

This separation matters because it lets different backends have entirely different trust and timeout requirements behind the same Traefik instance, for example a legacy backend with a self-signed certificate handled by one ServersTransport, and a hardened backend requiring mTLS handled by another, without either configuration leaking into the other.