Traefik Tcp Routers
You set up traefik tcp routers by linking an entry point to a backend service. These routers inspect raw network connections and forward packets based on host rules. Most engineering teams use this setup to expose databases or custom protocols outside a cluster. When network rules are too broad, anyone on the network can reach the backend port. A wide open port lets bad actors try brute force logins against your data stores. How traefik tcp routers handle raw traffic Standard web routers read
Traefik Middleware Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up traefik tcp routers by linking an entry point to a backend service. These routers inspect raw network connections and forward packets based on host rules. Most engineering teams use this setup to expose databases or custom protocols outside a cluster. When network rules are too broad, anyone on the network can reach the backend port. A wide open port lets bad actors try brute force logins against your data stores.
How traefik tcp routers handle raw traffic
Standard web routers read headers and paths to send requests to the right app. Raw transport routers work at a lower level and do not read web headers. They listen on a dedicated entry point port and wait for incoming network connections. When a client connects, the router checks the rule you wrote for that port.
If the connection uses TLS, the router can read the server name from the handshake. This lets you share one port across many backend databases or message queues. The router matches the server name and sends the stream to the right service. You can either terminate encryption at the router or pass encrypted bytes straight through.
If the protocol does not use TLS, the router cannot see a host name. You must use a catch-all rule that sends all port traffic to one backend. Each non-TLS service So, needs its own dedicated entry point port on the host. When both TCP and HTTP routers share a port, TCP rules run first. If no TCP rule matches the packet, the system hands the traffic to HTTP routers.
What native routing solves and what it misses
Native transport routing solves port management and TLS handling for non-web services. Your team does not need to manage separate load balancers for every database port. You can attach IP allowlists to block unknown networks before they reach the app. This keeps your network edge clean and puts all routing rules in one place.
Still, a network router only decides which packets can cross a port boundary. Once the connection opens, the router stays blind to the data inside the stream. It cannot tell which user logged in or what queries they run inside the session. A developer with valid database keys can still drop tables or pull sensitive records.
Traefik Middleware Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network logs only show source IP addresses, byte counts, and connection times. They do not record SQL statements, shell commands, or raw query outputs. Compliance teams need to know who ran a command and what data came back. They also need a way to mask emails, phone numbers, card numbers, and national IDs. Because raw routers only move bytes, they cannot rewrite matched fields in query results.
Best practices for production port routing
Start by separating public web ports from internal data ports on your hosts. Never put a database router on a public entry point without strict IP rules. Use TLS routing whenever your client tool supports server name checks during the handshake. This stops port sprawl and keeps your firewall rules simple and easy to read.
Keep TLS passthrough enabled when your backend database requires client certificate checks. If the router strips encryption early, the backend will not see the client certificate. Review your entry point list each month and shut down unused ports right away. Pair your network routing with strong database roles so users only get needed permissions.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can a TCP router and an HTTP router share the same port?
Yes, both router types can listen on the exact same entry point port. The system checks the TCP rules first and falls back to HTTP if nothing matches.
How do I route multiple databases over a single port?
Enable TLS on the router and match connections using the server name check rule. Each database client must send its target host name during the initial TLS handshake.
Does a TCP router log the queries sent to my database?
No, a raw transport router only logs connection events, IP addresses, and byte counts. It does not read or record the database queries running inside the network stream.