Custom TCP services behind protected IP: beyond an open port
Validate complete sessions, idle handling and disconnect behavior rather than only port reachability.
Contents of this article
Describe actual protocol behavior
Enterprise clients, data tools and games may use custom TCP. Document connection setup, message framing, authentication, idle periods, origin ports and server-initiated messages before choosing forwarding behavior.
Reachability does not prove application success
A port probe only verifies one network step. Use the real client for sign-in, reads, writes and normal closure. Distinguish connection-establishment failures from interrupted established sessions.
Align timeout and address-handling expectations
Align idle timeouts, keepalives and client-address handling. Enable extra proxy headers only when both sides support them; unexpected prefixes can break a private protocol.
Keep a controlled rollback path
Validate with a limited test group before broad cutover. Record address mappings, rollback steps and owners, then control retired public paths so they do not become permanent bypasses.
References
NGINX stream proxy documentation