Many SOCKS Connections Can Share One SSH Transport
ssh -D multiplexes destination streams over SSH channels; one outer TCP connection can still become their shared bottleneck.
One ssh -D process can serve several website connections at once. Count the layers separately:
| Layer | What it carries |
|---|---|
| Application to the SOCKS listener | Separate application connections and SOCKS requests |
| SSH channels | Independently addressed streams with channel-level flow control |
| SSH transport | Multiplexed channel data, commonly over one underlying TCP connection |
| Gateway to websites | Separate destination connections opened by the gateway |
Seeing one encrypted SSH socket therefore does not mean every website request is serialized into one destination connection. Dynamic forwarding relays stream data and opens new connections; it differs from a packet tunnel carrying the application's original TCP packets and IP headers inside another TCP connection.
The shared transport still matters. Capacity, scheduling, encryption work and transport loss or delay can affect several channels together. A stalled destination alone does not establish a one-channel limit.
If several applications slow down together, check whether they share the same SSH session and gateway path, then compare their actual workloads. Counting local SOCKS ports measures neither throughput nor independent routes. Multiplexing by itself promises no speed increase or separate public exit for each stream.