为何SOCKS5可穿透防火墙？已读SOCKS5 RFC仍有TCP/UDP数据包疑问

Great question—let’s break this down clearly, since SOCKS5’s ability to get past firewalls is easy to overlook even after digging through the RFCs. The key lies in how SOCKS5 wraps your actual traffic within a "legitimate" connection that firewalls are configured to allow, plus some clever handling for TCP vs. UDP.

First, How Most Firewalls Block Traffic #

Firewalls typically enforce outbound rules that filter traffic based on:

• Destination IP/port (e.g., only allowing traffic to port 80/443 for web browsing)
• Protocol type (TCP/UDP)
• In some cases, deep packet inspection (DPI) to check application-layer content (like HTTP headers)

They’re designed to block direct connections to restricted targets, but they often allow connections to trusted proxy servers or common service ports.

TCP Traffic: Relayed Through a Legitimate Connection #

SOCKS5 gets around TCP-based firewall restrictions by acting as an intermediary:

• First, your SOCKS5 client establishes a standard TCP connection with the proxy server (usually on port 1080, but many proxies let you use 80/443 to blend in with web traffic). Firewalls will allow this if the proxy’s IP/port is in their allowed list.
• During the SOCKS5 handshake, your client sends the target IP and port inside this existing TCP connection—not as a new outbound connection. The firewall only sees traffic between you and the proxy, not the target you’re actually trying to reach.
• The proxy then creates a separate TCP connection to your target server, relays data between you and the target through the initial TCP link. For the firewall, all traffic looks like regular communication with the proxy, so it doesn’t block it.
• If the proxy uses port 80/443, firewalls are even less likely to flag it—since those ports are reserved for HTTP/HTTPS, which are almost always allowed.

UDP Traffic: Bound Relay with Connection Context #

UDP is trickier because it’s connectionless, but SOCKS5 handles it with a binding step:

• Your client first establishes a TCP connection with the proxy and sends a UDP associate request. This tells the proxy you want to forward UDP traffic through it.
• The proxy assigns a temporary port to your client and sends it back. From then on, all your outgoing UDP packets are sent to this proxy port, wrapped with a SOCKS5 header that includes the target IP/port.
• The proxy strips the SOCKS5 header, forwards the original UDP packet to the target, and does the reverse for incoming packets (adds the header before sending back to you).
• Firewalls see UDP traffic between you and the proxy’s assigned port. Since you already validated the connection via TCP, most firewalls won’t block this UDP traffic—especially if it’s tied to an existing allowed TCP session.

The Big Picture #

SOCKS5 works because it hides your actual target traffic inside a connection that firewalls permit. Unless a firewall is specifically configured to detect and block SOCKS5 protocol traffic (via DPI), it can’t tell that you’re using the proxy to reach restricted targets. This is why it’s such a common tool for bypassing basic firewall rules.

内容的提问来源于stack exchange，提问作者Xiangting Liu