HAProxy in TCP mode: the HTTP signals you lose and what to watch instead

When a frontend and its backend run with mode tcp, HAProxy stops parsing the protocol inside the connection. It forwards bytes and nothing more. That is often correct: databases, gRPC, Redis, TLS passthrough, or protocols HAProxy does not understand. But it amputates a large part of the monitoring surface most HAProxy alerting assumes exists.

The failure mode this creates is not an outage; it is a blind spot. Dashboards that worked in HTTP mode start reporting zeros that look like “no traffic” or “no errors.” Health checks stay green while the application behind them is broken. Latency alerts keyed on rtime never fire again because rtime is permanently zero. The proxy is fine; your visibility into what flows through it is not.

This is a reference for what disappears in TCP mode, what connection-level signals remain, what to substitute, and when the honest answer is to use HTTP mode. For the broader HAProxy signal model, see the HAProxy guides hub.

What TCP mode changes about the signal surface

In HTTP mode, HAProxy terminates and re-originates every request: it parses headers, applies ACLs, counts response codes, measures per-request timing, and logs request-level detail. In TCP mode the pipeline collapses to: accept, select backend, queue if needed, connect, forward bytes, log at session close. There is no step where HAProxy sees a request or a response as a discrete object.

The monitoring consequence follows directly: any signal whose unit is “a request” or “a response” cannot exist. Signals whose unit is “a connection” or “a byte” still work.

flowchart LR
  subgraph HTTP["HTTP mode signal domains"]
    A1["req_rate / req_tot"]
    A2["hrsp_1xx..5xx"]
    A3["rtime (first-byte)"]
    A4["comp_* compression"]
    A5["L7 health checks"]
    A6["httplog: %ST, %r, headers"]
  end
  subgraph TCP["TCP mode signal domains"]
    B1["scur / slim / rate"]
    B2["econ / eresp / wretr / wredis"]
    B3["qcur / qtime / ctime / ttime"]
    B4["bin / bout"]
    B5["cli_abrt / srv_abrt"]
    B6["L4 health checks (L6 for TLS)"]
  end
  HTTP -. "mode tcp: all lost" .-> X["not available"]
  TCP --> Y["still collected"]

The HTTP signals you lose

These stats CSV fields are HTTP-only. In TCP mode they are zero or meaningless, and any alert built on them goes silently deaf.

The logging loss deserves emphasis. TCP mode uses option tcplog, whose default format is roughly "%ci:%cp [%tr] %ft %b/%s %Tw/%Tc/%Tt %B %ts %ac/%fc/%bc/%sc/%rc %sq/%bq". You get timing, bytes, and termination state, but no status code and no request line. One line is emitted per session, not per request, and for a long-lived connection that line arrives only when the session closes. If you set option httplog in defaults and a frontend is mode tcp, HAProxy warns and downgrades that frontend to tcplog.

Two more practical consequences:

• The stats page itself must be served from an HTTP-mode listener. If you convert all frontends to TCP mode and the stats endpoint stops responding, that is why. Keep a small dedicated mode http frontend for stats and metrics.
• Prometheus metrics such as haproxy_frontend_http_requests_total and haproxy_server_http_responses_total are HTTP-only and will be zero or absent for TCP-mode proxies.

What remains: the connection-level signal set

Everything measured per connection, per byte, or per session survives. This is your entire signal budget in TCP mode, and it is smaller than it looks:

Global show info signals are mode-independent and still fully available: CurrConns/Maxconn, ConnRate/SessRate, Idle_pct (with the usual busy-polling caveat), PoolFailed, Ulimit-n/Maxsock, DroppedLogs, Run_queue/Tasks, and the SSL frontend fields if you terminate TLS.

What to substitute for the missing HTTP visibility

The substitutions are weaker than the originals. Know the gap each one leaves.

For request rate, use session rate plus bytes. rate on the frontend counts new TCP connections per second. For chatty protocols (many short connections) it tracks workload well. For pooled or persistent protocols (database drivers with connection pools, gRPC with long-lived channels) it tells you almost nothing about actual query volume; a flat session rate can hide a 10x change in work per connection. bin/bout rates are the fallback volume signal. Neither substitutes for a real application-side request metric, which is the right fix: instrument the application, not the proxy.

For response codes, use the error triad: econ, eresp, srv_abrt. There is no 4xx/5xx axis in TCP mode, so “application returning errors” is invisible at the proxy. What you can see:

• econ rising: cannot connect. Backend down, overloaded accept queue, network, or ephemeral port exhaustion.
• eresp rising: connected, but the server closed unexpectedly. Crash mid-session, kill, or protocol the server rejected.
• srv_abrt rising: server aborted an in-flight transfer.
• cli_abrt rising: clients giving up. Your closest proxy for user-perceived slowness, the same role it plays in HTTP mode.

Correlate econ with ctime to separate refusal from timeout: high ctime before econ spikes means connect timeouts; near-zero ctime with econ means immediate refusal.

For rtime, there is no substitute at the proxy. HAProxy cannot measure time-to-first-byte for a protocol it does not parse. ctime covers the network and the backend’s accept path. ttime covers whole-session duration, which for long-lived protocols is dominated by session lifetime, not operation latency. If you need operation latency in TCP mode, it must come from the application or from protocol-aware tooling on the backend side. Plan for this before migrating a frontend to TCP mode, not after.

For L7 health checks, use option tcp-check with send/expect. A plain check in TCP mode verifies only that the port accepts connections and produces L4 result codes: L4OK, L4TOUT (layer 1-4 timeout), L4CON (connection problem such as refused or no route to host). For TLS-wrapped checks you get L6 codes. That is exactly the “health check green, app broken” trap: the port accepts, the application speaks garbage, HAProxy keeps routing. option tcp-check lets you send a probe string and expect a specific reply, validating the application protocol over TCP (for example, a Redis PING expecting +PONG). It is more work to configure and more brittle than an HTTP check, but it is the difference between checking the socket and checking the service.

For per-request forensics, use termination state codes and session timing in tcplog. The %ts termination state and the Tw/Tc/Tt timers are still logged per session. Watching for timeout and reset termination states in logs is more sensitive than any aggregate counter for certain failure patterns, and it works identically in TCP mode.

When to prefer HTTP mode

TCP mode is the right choice when HAProxy does not speak the protocol (databases, Redis, LDAP, arbitrary binary protocols), when you need TLS passthrough with end-to-end encryption, or when you deliberately want minimal per-connection overhead.

Prefer HTTP mode when any of these are load-bearing for your operations:

• Your error alerting is built on hrsp_4xx/hrsp_5xx ratios or the frontend-minus-backend 5xx delta.
• Your latency alerting uses rtime or per-request percentiles from httplog.
• Your health checks need to verify application behavior, not socket behavior.
• You route on content: paths, headers, hosts, methods.
• You need connection reuse accounting (connect vs reuse), compression visibility, or request-level stick-table tracking such as http_req_rate per source.

A mixed deployment is normal and supported: some frontends in TCP mode, others in HTTP mode, with each frontend and its paired backend in the same mode. The operational rule is that your monitoring must be mode-aware per proxy. An alert that assumes HTTP fields exist will silently report zeros for TCP-mode objects, and zero is ambiguous: it can mean “no traffic,” “no errors,” or “this field does not exist here.”

Signals to watch in production

For a TCP-mode frontend/backend pair, this is the minimum set that preserves real diagnostic power:

How Netdata helps

• Netdata collects the full HAProxy stats CSV per proxy and labels rows by frontend, backend, and server, so TCP-mode objects show their real signal set (sessions, queue, timing, errors, bytes) instead of misleading zeros on HTTP charts.
• Session saturation is visible as scur against slim at global, frontend, backend, and per-server levels simultaneously, which matters because TCP-mode proxies bottleneck at whichever of the four maxconn levels is tightest.
• Correlating econ, eresp, srv_abrt, and cli_abrt on one timeline is the TCP-mode replacement for response-code analysis; per-second granularity makes the refuse-versus-timeout distinction (via ctime) practical during an incident.
• Queue signals (qcur, qtime) alongside per-server scur show connection-slot exhaustion as it develops, which in TCP mode is the earliest warning before clients see connect failures.
• Anomaly detection on rate and byte throughput gives baseline-deviation alerting on the only traffic-volume signals TCP mode still produces, without hand-tuned thresholds per proxy.

Related guides

• HAProxy 502 Bad Gateway: backend connection and response failures
• HAProxy 503 Service Unavailable: no server is available to handle this request
• HAProxy 504 Gateway Timeout: timeout server and the backend timeout cascade
• HAProxy backend losing servers: active server count and cascade risk
• HAProxy backend queue building (qcur): requests waiting for a free server slot
• HAProxy bandwidth (bin/bout): bytes in, bytes out, and capacity planning
• HAProxy compression overhead: comp_byp, CPU cost, and when compression backfires
• HAProxy connect time (ctime) high: network latency and backend accept-queue overflow
• HAProxy connection errors (econ): backend connections refused, timed out, or reset
• HAProxy connection reuse dropping: http-reuse, pooling, and handshake overhead
• HAProxy counter resets on reload: phantom drops and spikes in your metrics
• HAProxy scur approaching slim: the concurrent-session saturation signal