I've spent some time looking into the SOCKs support in ATS (or maybe former SOCKS support is more accurate)
SOCKS support is present in every ATS. The define that enables it is Here <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/I_Socks.h#L31>, There isn't an option to switch it on or off in configure. Its not documented in recent ATS versions but you can piece together information from Here <http://mail-archives.apache.org/mod_mbox/trafficserver-users/201411.mbox/%3CCAE2_gsVvj=UJqEPYfEDxpUg_cp+dhs2_9oEeNmVNOeH6YFL=f...@mail.gmail.com%3E> , Here <https://www.websense.com/content/support/library/web/v76/wcg_help/sokpvars.aspx> , and Here <https://gist.github.com/piotrbulinski/9396189>. And there is an open Jira to update the documentation Here <https://issues.apache.org/jira/browse/TS-2513> Once you get past that its really tough to trigger the code - I added these entries to records.config: CONFIG proxy.config.socks.socks_needed=1 CONFIG proxy.config.socks.default_servers=<socks_server_ip>:<socks_port> And for added measure I added this line to socks.config: dest_ip=0.0.0.0-255.255.255.255 parent="<socks_server_ip>:<socks_port>" However, none of those items seemed to have any effect - all the outgoing traffic from ATS still went direct, there were no connections to the socks server. Eventually I resorted to forcing ATS to select the socks path Here <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/UnixNetProcessor.cc#L202> . It turns out that the socks code has issues with IPV6, and even if your not using IPV6 but are on a host with IPV6 capability you fail an assert Here <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/Socks.cc#L65>. And I'm not the first one to find that, see Here <https://issues.apache.org/jira/browse/TS-2482> And if you work around that then you eventually segfault (not sure where in the code): traffic_server: Segmentation fault (Address not mapped to object [0x24])traffic_server - STACK TRACE: /home/me/ats/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac079] /lib64/libpthread.so.0[0x38e340f710] /home/me/ats/bin/traffic_server(_ZN18ParentConfigParams10findParentEP15HttpRequestDataP12ParentResult+0x28)[0x4e0f38] /home/me/ats/bin/traffic_server(_ZN10SocksEntry10findServerEv+0x15a)[0x74118a] /home/me/ats/bin/traffic_server(_ZN10SocksEntry4initEP10ProxyMutexP18UnixNetVConnectionhh+0x855)[0x742605] It looks like the core issue is with how ATS selects the outgoing address of Socks connections. Socks5 technically supports IPV6, but socks4/4a does not, so when resolving names for Socks only IPv4 addresses should be considered. However, most socks servers are capable of doing their own name resolution and TOR (probably the most popular thing using socks right now) would prefer to do its own name resolution, so the best solution might be to pass through FQDNs which is supported by socks 4a and 5. Beyond that the address we are connecting to is the address of the socks server and I don't think that is being resolved for some reason. BTW, the current SOCKS support hard codes the authorization parameters of the socks server and thats probably sufficient for one person behind a proxy, However, for more then one person behind a -caching- proxy that probably not sufficient, if the server needs authorization we should probably pass through the username:password from the Proxy-Authorization details or return the client a 407 if not present/declined. It looks like the closest anyone has come to fixing socks in recent times was Here <https://issues.apache.org/jira/browse/TS-803>, I'm not sure how his fix worked or if its still appropriate for the current ATS. I'm hoping that there is enough here that someone more seasoned would be inspired to look into it. I'll continue to look at it but I'm not familiar with the code base so it could be a while before I can contribute much more then analysis.
