透明 TCP 到 SOCKS 转发中的原始目的地址
解释透明 TCP 到 SOCKS 转发为何需要先恢复原始目的地址、再与代理协商的转换组件。
防火墙可以改变一条 TCP 连接最终落到哪里。但仅仅做出这个改变，它并不能教会发起连接的应用去说 SOCKS。
普通的 SOCKS 服务器期待一段描述所请求目的地的协商。而不知道代理存在的应用，反而会立刻发送自己的协议字节。把这些字节直接重定向到 SOCKS 监听端，双方就会对第一条消息产生分歧。
缺失的组件是一个转换器
透明的 TCP 到代理组件就坐落在这些接口之间。它查明应用最初请求的目的地，建立合适的 SOCKS 或 HTTP CONNECT 会话，然后在这条建立起来的流上转发应用数据。
在其 Linux iptables 路径上，redsocks 的源码通过 SO_ORIGINAL_DST 取出被保留的目的地。其他操作系统和重定向方式使用不同的机制。这是重定向器和网络配置的性质，而不是普通 SOCKS 客户端的功能。
原始目的地信息也解释了为什么把一条重定向规则从代理主机移到无关的网关并不总是等价。接收进程需要其拦截方式所要求的元数据。在别处被改写的地址，可能不再以预期的形式提供这一信息。
要明确转换器的适用范围。一条能正常工作的重定向 TCP 连接，并不能证明它支持任意的 UDP、ICMP 或每一条解析路径。上游代理协议和转换器的实现仍然决定着所支持的操作。
当某个配置在连接之后立刻失败时，先检查协议边界，再考虑扩大访问规则。一个完全可达的 SOCKS 监听端，也可能拒绝那些从来就不是 SOCKS 请求的字节。