Nginx Tcp Forward
You set up an nginx tcp forward using the built-in stream module. This module routes raw network packets from a public port to an internal backend. Teams often use this method to expose private databases or internal services to developers. Still, opening a raw network port gives every allowed user full reach to the service. If a team shares broad database roles, any user on that port can change data. How an nginx tcp forward works in practice Web servers usually read and route web traffic at
NGINX Security Configuration + Forward Proxy Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an nginx tcp forward using the built-in stream module. This module routes raw network packets from a public port to an internal backend. Teams often use this method to expose private databases or internal services to developers. Still, opening a raw network port gives every allowed user full reach to the service. If a team shares broad database roles, any user on that port can change data.
How an nginx tcp forward works in practice
Web servers usually read and route web traffic at the app layer. When you need to route database or custom binary traffic, you must drop down. The stream module works at layer four of the network stack. It does not read web headers, paths, or cookies. Instead, it listens on a set TCP port and opens a link to the backend.
To set this up, an engineer defines a stream block in the main file. This block sits outside the standard web server block. Inside the stream block, you list an upstream group with your backend server addresses. Then you define a server block that listens on a chosen port. It forwards every incoming byte straight to that upstream group.
Nginx can also wrap this traffic in TLS encryption. It can handle the TLS handshake with the client and send plain TCP to the backend. Or it can pass the encrypted stream right through without reading it. Load balancing works here too. You can spread new TCP links across several backend nodes using round-robin or least-active rules.
Network limits and access control in the stream module
Because the stream module works at layer four, its access rules stay at the network level. You can restrict who reaches the port by listing allowed client IP addresses. You can also require client TLS certificates to check who is on the wire. For health checks, the server tests if the backend port accepts a basic TCP handshake.
Logging in the stream module also stays at the transport layer. Each log line records the client IP, the bytes sent, and the session length. You can see when a session starts and when it ends. This setup works well when you only need to move packets across network zones.
NGINX Security Configuration + Forward Proxy Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What raw TCP forwarding solves and what it misses
An nginx tcp forward solves the basic routing problem for private networks. It lets you keep databases off the public internet while giving one entry point. It also handles load distribution and TLS offloading for non-web services. Network teams like it because it is fast and uses a tool they already run.
Still, a layer four forwarder is blind to the protocol inside the TCP stream. Once a client passes the IP check, the server just copies bytes back and forth. It cannot see which user logged into the database or which queries they ran. It cannot tell a safe read query from a command that drops a table.
It also cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs. Every query result passes back to the client in its raw form. Also, developers still need real database passwords on their laptops to log in. If you want to audit commands or mask data, raw TCP forwarding leaves a gap.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Where do I place the stream block for TCP forwarding?
Place the stream block at the root level of your main server file. It must sit alongside the main web block, not inside it.
Can an nginx tcp forward route traffic by hostname?
Plain TCP has no hostname header, so standard ports cannot route by name. Still, if the traffic uses TLS, the stream module can read the SNI hostname.
Does TCP forwarding log the database queries that users run?
No, the stream module only logs network metadata like IP addresses and byte counts. It does not decode database protocols or record individual SQL statements.