SOCKS 5 協議（RFC 1928）是網路防火牆穿透技術的基石，它為 TCP/UDP 應用程式提供了一個通用、安全的代理框架。本文將系統性梳理協議架構、認證協商、請求/應答格式、UDP 轉發機制以及安全性考量，幫助開發者快速掌握核心細節。
SOCKS 5 定位於應用層與傳輸層之間的「中介層」，不處理 ICMP 等網路層封包。相較於 SOCKS 4 僅支援 TCP 且無認證，版本 5 新增了：
客戶端連接 SOCKS 伺服器（預設埠 1080）後，雙方進行版本與方法協商：
客戶端 → 伺服器：VER=0x05, NMETHODS, METHODS[]
伺服器 → 客戶端：VER=0x05, METHOD
若伺服器回應 0xFF 表示無可接受方法，客戶端須關閉連線。RFC 強制實作需支援 GSSAPI，並建議支援用戶名/密碼（0x02）。
認證完成後，客戶端發送請求：
| 欄位 | 長度 | 說明 |
|---|---|---|
| VER | 1 | 0x05 |
| CMD | 1 | 0x01 CONNECT / 0x02 BIND / 0x03 UDP ASSOCIATE |
| RSV | 1 | 保留 0x00 |
| ATYP | 1 | 0x01 IPv4 / 0x03 域名 / 0x04 IPv6 |
| DST.ADDR | Variable | 目的地址 |
| DST.PORT | 2 | 網路序連接埠 |
VER REP RSV ATYP BND.ADDR BND.PORT
關鍵回應碼：0x00 成功、0x05 連線被拒、0x07 不支援命令、0x08 不支援地址類型。BIND 命令會產生兩次應答（監聽建立、連線到達）。
UDP ASSOCIATE 建立轉發管道後，每個 UDP 資料報前綴固定標頭：
RSV(2) FRAG(1) ATYP(1) DST.ADDR DST.PORT DATA
協議本身不加密，安全性完全仰賴協商的認證/封裝方法。管理員應：
SOCKS 5 以極簡設計解決了防火牆穿透的通用需求，其協商機制與地址抽象使上層應用無感知地獲得代理能力。理解協議細節對開發代理用戶端、伺服器或防火牆審計工具至關重要。
