What is the difference between a TCP port check and an HTTP check; which should I choose?

Short answer

A TCP check only looks at whether the port accepts connections; even if the application returns an error page or hangs, the server appears healthy if the port is open. An HTTP check sends a request, verifies the status code with Expected Status Codes (default 200) and optionally the response content with Content Check Mode; therefore it also catches application failures. HTTP or HTTPS is selected for web applications and APIs, and TCP for services that do not speak HTTP (databases, custom protocols); if needed, data suitable for the protocol is sent with TCP Scenario and a response is waited for.

How Does It Work?

• TCP: TR7 opens a TCP connection to the address and port of the Backend Service. If the connection is established within the Timeout duration, the check is successful. If TCP scenario is on, the steps are run in order after the connection (Send text, Expect text, Expect regex, Wait(ms)).
• HTTP: TR7 sends a request to the Backend Service with the Method (default GET) to the Path + Query address (/ if empty). The status code of the response must be in the Expected Status Codes list, and if a content check is defined, the response body must also meet the condition. Redirects (301/302) are not followed.
• HTTPS: The HTTP check is performed over a TLS connection. The client certificate (mTLS) and verification CA profile defined in the Backend Service, together with the lowest TLS version and the cipher list of its Backend SSL Security Profile, are also applied to the check connection (the highest version and the curve are not carried over); if a separate selection has been made in the profile, the selection in the profile applies (Backend Services · Health Check).

Comparison

	TCP	HTTP / HTTPS
Checked	The port accepting connections	The status code and content of the response to the request
Does it catch application failures	No (partially, if a protocol response is waited for with TCP scenario)	Yes (status code, content, JSONata expression)
Additional setting	Optional TCP scenario	Path + Query, Method, HTTP version, HTTP headers, HTTP body, Expected Status Codes, Content Check Mode, Virtual Domain (Host/SNI)
Load on the server	Very low	Low (with a lightweight health address)
Suitable service	Database, RDP, custom TCP protocols	Web, API, any HTTP-based service

In TR7

• Web and API services: HTTP or HTTPS; a /health address that returns the actual status of the application and a content check are recommended (Operational best practices).
• If the server expects TLS: HTTPS; the TLS settings in the Backend Service are applied to the check automatically.
• Non-HTTP TCP services: TCP; if possible, the server's greeting message is waited for with TCP scenario.
• UDP services: DNS for DNS, UDP with UDP Scenario for the others.
• Profile: Load Balancer → Profiles → Health Checks → Add; Check Type cannot be changed after saving.

Common Misconceptions

• "TCP is enough; if the port is open, the application is running." Even if the application crashes, the web server can keep the port open.
• "The HTTP check follows redirects." It does not; if the health address returns 301/302, this code is added to the Expected Status Codes list (How do I expect a specific status code (e.g. 200, 302) in an HTTP health check?).
• "The HTTP check puts load on the server." When a lightweight health address is used, the load is negligible.

How it is done in the documentation

• Health Checks · Operational Best Practices
• Health Checks · TCP
• Health Checks · HTTP
• Health Checks · TCP Scenario

Related questions

• Which health check types are supported?
• What kind of /health endpoint should I design in my application for health checks?
• How do I verify a specific text (e.g. "OK") in the response content?