TCP Probe Configuration in Proberix

This article provides a comprehensive guide to setting up and configuring TCP probes in Proberix, allowing you to monitor services that rely on raw TCP connections rather than HTTP/S protocols.

Required Configuration

When creating a TCP probe, the following fields are required:

Host/IP:
The host or IP address of the service you wish to monitor. Note that the host cannot be a localhost or an address from a local network (e.g., 192.168.x.x or 10.x.x.x), as Proberix monitors publicly accessible endpoints.

Port:
The port number to which the probe will connect. This should correspond to the specific service you want to monitor (e.g., 22 for SSH, 443 for HTTPS, or any custom port your service uses).

These two fields are the minimum required to configure a TCP probe in Proberix.

Optional Configuration

Use Secure Connection (SSL/TLS):
When enabled, the probe establishes a TLS-encrypted connection instead of plain TCP. This is useful for services running on secure ports such as 443 (HTTPS), 993 (IMAP), or any custom service using TLS.

Enforce Certificate Validation (Reject Invalid):
When enabled, the probe will validate the server's TLS certificate and reject the connection if it is self-signed, expired, or mismatched. If disabled, the probe will still connect even if the certificate is untrusted — useful for internal services or testing environments with non-public certs.

Payload:
An optional string to send immediately after the TCP connection is established. This can be used to trigger a protocol response (e.g., sending HELO for SMTP or a custom request for internal services).

Payload Encoding:
Specifies how the payload should be encoded before being sent. This is important when working with binary protocols or non-text data.

Supported values:

• Plain (UTF-8 text)
• Hex
• Base64

Line Ending (Visible only when Plain Text is selected):
Selects how line breaks are encoded in the payload. Some protocols require specific line endings to function correctly.

• LF (\n) — Line Feed only
• CRLF (\r\n) — Carriage Return + Line Feed (required by protocols like SMTP and HTTP/1.1)

The selected line ending will be applied to any newlines in the payload input when the data is transmitted.

Response Validation:
Define patterns that the TCP response must match. This is useful for checking protocol banners, handshake replies, or custom binary data returned after sending a payload.

For full details, see the Response Validation documentation.

Enable Change Detection:
When enabled, the probe monitors changes in the TCP response body across executions. This is useful for detecting unexpected shifts in protocol responses, banners, or custom service output.

For details on how change tracking works, refer to Change Detection Documentation.

General Settings

HTTP/S and TCP probes share similar general settings for monitoring intervals, locations, and how notifications are handled. These settings allow you to define how frequently probes are performed, from which geographic locations, and the configuration of alert notifications. For detailed instructions, refer to the General Settings Documentation.

Monitoring Process

When a TCP probe is executed, Proberix performs the following steps:

1. Attempts to establish a TCP (or TLS, if configured) connection to the specified host and port, using a fixed timeout of 5 seconds.
2. If a payload is configured, it is sent immediately after the connection is established.
3. If response validation is enabled, the probe waits up to 10 seconds for a response and checks it against the defined patterns.
4. If no validation is configured but a payload was sent, the probe briefly waits for a response (up to 10 seconds), but does not treat the absence of one as a failure.
5. If neither a payload nor validation is configured, the probe performs a lightweight port check by peeking briefly for a response (with a 200ms read timeout).
6. Based on connection success and optional validation, the result is marked as "ok", "mismatch", or "unreachable", and the response (if any) is stored for up to 7 days. Probe statistics such as connection and response times are stored for 6 months.

This process ensures that the monitoring is lightweight and efficient, making it suitable for real-time checks of TCP-based services.

Best Practices

• Ensure that the host or IP address is publicly accessible and not restricted by a firewall unless you explicitly allowlist the Proberix IPs.
• Choose a monitoring interval that balances timely alerts with the resource demands of frequent probes.
• If the service requires high availability, consider selecting multiple monitoring locations to ensure redundancy in monitoring.

Advanced Considerations

While Proberix does not require detailed knowledge of the underlying TCP implementation, it’s important to understand that TCP probes focus solely on connection-level monitoring. They do not evaluate application-layer protocols like HTTP, but they are effective for monitoring services such as SSH, custom TCP-based APIs, or any system where availability can be assessed by the ability to establish a connection.