Fixed-Destination TCP Relaying with Windows portproxy
A portproxy rule forwards a listener to a fixed destination. It does not add the SOCKS or HTTP CONNECT negotiation expected by proxy-aware clients.
A Windows portproxy rule relays TCP to one configured destination. It does not negotiate a browser's HTTP proxy request or a SOCKS destination request.
| Service | Who selects the destination? |
|---|---|
| Fixed TCP relay | The listener's forwarding configuration. |
| SOCKS5 proxy | The client request, within server policy. |
| HTTP forward proxy | The HTTP proxy request, including CONNECT for common HTTPS tunneling. |
Inspect an existing relay with netsh interface portproxy show all. Compare its configured backend with the protocol your client sends. The netsh reference describes listener and destination addresses/ports; accepting TCP does not establish an HTTP or SOCKS handshake.
A SOCKS negotiation sent to an ordinary relay simply reaches that fixed backend. It cannot make a non-SOCKS service understand the request or choose a new target.
A relay in front of a real proxy is different. The upstream proxy still negotiates destinations and authentication; the relay carries the connection to it. A network-exposed relay can extend access to that backend, so keep the listener's access boundary deliberate.
Choose a protocol-capable service when the requirement is a general HTTP or SOCKS exit. A forwarded port is only one part of that path.