Stream Mode

What Stream Mode Does

Stream mode is the gateway’s non-HTTP operating mode for layer 4 traffic, so it works at the connection level rather than the request-and-response level. That makes it the right fit when the gateway must pass, route, or secure protocols such as SSH, email, and database connections that do not speak HTTP semantics.

Because stream mode sees raw TCP sessions, it does not inspect application requests the way layer 7 routing does. The practical trade-off is breadth versus application awareness: you can support more protocols, but you also lose some of the policy richness, header inspection, and content-based controls available in HTTP-aware proxying.

Why Layer 4 Routing Matters

Layer 4 mode exists to preserve connectivity for protocols that are not naturally expressed as web requests. In practice, this is how a gateway can front services like PostgreSQL, SMTP, IMAP, or SSH without forcing them into an HTTP model they do not use.

That broader protocol support is operationally important in mixed environments, especially where the gateway sits between clients and internal services. The gateway still brokers the connection, but the decision surface is transport-oriented, typically based on destination, port, or session properties rather than URL paths or HTTP methods.

For teams standardizing ingress, stream mode is often the bridge between modern edge policy and legacy or non-web infrastructure. It is also where careful mapping of ports and upstream targets becomes part of the design, because the gateway is no longer interpreting application intent on behalf of the service.

How Stream Mode Differs from HTTP Proxying

HTTP proxying understands requests, methods, headers, cookies, and sometimes application-layer identity signals. Stream mode does not, so it cannot make the same kind of content-aware routing decisions. Instead, it treats the traffic as a persistent byte stream over TCP.

That difference changes what the gateway can enforce. In HTTP mode, controls can be tied to routes, hosts, and request attributes. In stream mode, controls are usually limited to connection-level routing, TLS termination or passthrough choices, and basic session handling. The result is simpler protocol support, but a narrower security policy model.

This distinction matters when an organisation assumes one gateway pattern fits every workload. If a service depends on protocol features outside HTTP, stream mode may be the only workable option, but it should be adopted with clear awareness of the reduced visibility into what is actually happening inside the session.

Common Uses and Design Trade-offs

Stream mode is most useful where the service speaks native TCP and the gateway only needs to steer the connection to the correct backend. That is common for administrative access, messaging systems, and data services that would be awkward or impossible to expose through HTTP semantics.

The design trade-off is that a gateway in stream mode can protect the transport path without understanding the higher-level application transaction. That means fewer opportunities for request-level policy, but also fewer assumptions about protocol shape. In heterogeneous environments, that flexibility is often the reason stream mode exists at all.

In practice, the mode should be chosen because the workload needs layer 4 handling, not because it is a convenient default. When the traffic is actually HTTP, layer 7 routing is usually the better fit because it can express richer policy and observability.

Risk and Threat Considerations

Stream mode can create blind spots if teams assume gateway presence automatically means application-level control. Because the gateway only sees a TCP stream, weak upstream segmentation, overly broad exposure, or unsafe protocol defaults may be harder to detect and govern than in an HTTP-aware setup.

Failure mechanism: An organisation may place sensitive services behind a gateway and incorrectly believe the gateway is inspecting or constraining application activity, when in fact it is only forwarding raw connections. That can leave permissive access paths, weak service authentication, or unsafe port exposure in place.

Impact: The main consequences are reduced inspection depth, weaker policy granularity, and a larger chance that exposed services will rely on their own hardening rather than the gateway to absorb risk.

Practitioner Guidance

What to watch for: Use stream mode only when the service genuinely needs non-HTTP transport handling. If the workload later grows HTTP endpoints or application-aware policy needs, revisit whether a layer 7 pattern is more appropriate for that traffic.

Governance implication: Treat stream-mode routes as infrastructure connectivity controls, not as a substitute for service hardening. The owning team should be able to explain what protocol is being forwarded, why HTTP inspection is not possible, and where security enforcement actually occurs.

Practitioner takeaway: Stream mode is a transport solution first, so its security posture depends on disciplined exposure management, upstream service controls, and clear ownership of the protocols it forwards.

Related resources from NHI Mgmt Group

• What is the difference between sandbox mode and true network isolation for AI workloads?
• What breaks when code mode gives agents more runtime freedom?
• What breaks when agent mode can take autonomous multi-step actions?
• When should organisations use URL-mode instead of form-mode elicitation?