有一种代理IP连接是反着来的——不是你的设备主动去找目标站，而是目标站反过来连到你这边。这就是 SOCKS5 里的 BIND 模式，平时不常见，但在某些特定场景里，它才是唯一能走通的路。
先说结论：BIND 模式的本质是让代理IP服务器先开一个端口等着，等目标站主动连过来，再把数据接上。它和日常用的 CONNECT 模式正好相反，一个是出去找，一个是等门来。
BIND 是什么
在 SOCKS5 协议里，命令字段除了最常用的 CONNECT（建立出站连接），还有 BIND（绑定监听）和 UDP ASSOCIATE（UDP 关联）。BIND 的工作方式是：客户端先请求服务器绑定一个端口，服务器开好端口后把地址报给客户端，客户端再把地址转告给目标站，目标站据此连进来。
整个过程分两段：第一段客户端和服务器完成握手并拿到监听地址，第二段目标站连上服务器开好的端口。数据链路建立之后，双向传输和普通连接没有区别。
BIND 用在什么时候
最典型的场景是 FTP 的被动模式。FTP 数据连接有时需要服务器方向发起，走普通出站代理连不通，这时 BIND 模式就派上了用场。此外，一些需要外部回调的协议和工具，也会用到这种反向建连的思路。
第一步，请求绑定。客户端向代理IP服务器发出 BIND 命令，说明希望服务器开一个监听端口。
第二步，服务器回报地址。服务器开好端口后，把地址和端口号通过应答消息报给客户端。
第三步，转告目标站。客户端拿到地址后，把它交给真正需要连进来的那一方。
第四步，连接建立。目标站按地址连上服务器，双向数据开始传输，和普通连接一样工作。
BIND 和 CONNECT 的差别
CONNECT 是客户端指路、代理IP去连；BIND 是客户端请求代理开个门、让别处的人进来。两者方向相反，用途也完全不同，选错模式，连接必然失败。
对多数业务来说，用到的都是 CONNECT，BIND 属于特定场景的补充能力。如果你遇到“需要外部主动连入”的协议场景，记得检查代理IP服务商是否支持 BIND，以及客户端工具是否暴露了这个选项。
BIND 模式对安全性的要求也更高。因为服务器要开一个对外可连的监听端口，这个端口相当于在防火墙里临时开了个口子，配置不当容易被当作入口利用。正规的代理IP服务商通常会把 BIND 的监听范围、端口生命周期都管理得很仔细，使用方则要确认自己的场景确实需要它，而不是随手开启。安全这条线，配置任何模式时都值得多看一眼。
理解这两种模式的分工，配置代理IP时就不会在连接方向问题上反复试错。用到反向连接的需求不多，但真遇到时，知道有 BIND 这一扇门，思路就打开了。