Traefik Tcp Router
You set up a traefik tcp router by linking an entry point to a service. This setup uses host rules or raw port rules to direct network traffic. Teams often use this method to expose databases and internal apps to their staff. Still, opening network ports with broad rules gives every user full network reach. Once a user passes the port check, the router cannot inspect their actions. How a traefik tcp router directs network traffic A traefik tcp router listens on a chosen network port called an
Traefik Middleware Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a traefik tcp router by linking an entry point to a service. This setup uses host rules or raw port rules to direct network traffic. Teams often use this method to expose databases and internal apps to their staff. Still, opening network ports with broad rules gives every user full network reach. Once a user passes the port check, the router cannot inspect their actions.
How a traefik tcp router directs network traffic
A traefik tcp router listens on a chosen network port called an entry point. When a packet arrives, the router checks its rules to find a match. If the traffic uses TLS, the router reads the server name from the handshake. This lets one port send traffic to many backend apps based on the domain. If the traffic does not use TLS, the router uses a catch-all rule. A catch-all rule sends every packet on that port to a single service.
Teams also choose how the router handles encryption for each backend app. The router can end the TLS session itself and send plain traffic inward. Or, it can pass the encrypted bytes straight through to the backend server. After the router picks a backend service, it opens a direct pipe. Bytes flow back and forth between the client and the server without more checks.
To restrict who can reach the port, teams add IP filter rules. These filters check the source IP address of the client before opening the pipe. Some teams also require client certificates during the TLS handshake to check identity. If the IP address or certificate matches, the router allows the session to start.
Why teams separate TCP and HTTP routing
Many apps do not speak HTTP and need raw TCP pipes to work. Databases, mail servers, and message queues use their own binary wire formats. An HTTP router cannot read these formats and will drop the traffic. By using a TCP router, teams can manage both web apps and data stores. Both router types can even share the same port when TLS is active.
When both router types share a port, the TCP rules run first. The router checks if any TCP rule matches the incoming stream. If no rule matches, it passes the traffic to the HTTP routers. This order helps teams keep a clean network setup with fewer open ports. Still, sharing ports requires careful rule planning so traffic goes to the right place.
Traefik Middleware Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network routing solves and what it leaves open
A TCP router is great at directing network packets and managing TLS certificates. It hides internal server addresses and gives teams a single entry point to manage. IP filters and client certificates also help block unknown outsiders at the network edge. For basic network transport, this setup does its job well.
Still, a TCP router only sees raw bytes after the session starts. It decides who can reach the port, not what commands they run inside. Once an engineer logs in to a database, the router is blind to queries. It cannot stop a destructive delete command or log which table a user read. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers. Every user who passes the network check gets full power over that stream.
Also, clients still need static database passwords or keys on their local machines. The router just passes the login handshake through to the backend service. If a laptop is lost, those saved keys put the backend data at risk. Network routing alone cannot enforce fine-grained rules on live commands or results.
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
Can a traefik tcp router share a port with an HTTP router?
Yes, both router types can listen on the same network entry point. The TCP router evaluates its rules first when traffic uses TLS. If no TCP rule matches, the HTTP router handles the request.
How does a TCP router route traffic to multiple services on one port?
It reads the Server Name Indication field during the initial TLS handshake. This field tells the router which hostname the client wants to reach. Without TLS, one port can only route to one backend service.
Can a TCP router inspect or block specific database queries?
No, a TCP router operates at the transport layer and only moves raw bytes. It cannot parse database wire protocols or read individual SQL statements. You need a protocol-aware layer to inspect queries or rewrite emails in results.