search

rofl0r / proxychains-ng

proxychains ng (new generation) - a preloader which hooks calls to sockets in dynamically linked programs and redirects it through one or more socks/http proxies. continuation of the unmaintained proxychains project. the sf.net page is currently not updated, use releases from github release page instead.
http://sourceforge.net/projects/proxychains-ng/files
GNU General Public License v2.0
9.82k stars 1.08k forks source link

random_chain: keep iterating through the list on proxy error #432

Open jeremyp3 opened 2 years ago

jeremyp3 commented 2 years ago

hi,

I happen to use high traffic proxies that work intermittently. When the proxy cannot provide me with the requested resource, it returns a 97 error with curl. With proxychains, it says "[proxychains] Random chain "socket error or timeout!" and it does not try to contact anyone else proxy from my list, unlike unresponsive proxies.

I think it would be better if proxychains doesn't stop on an error proxy, but continues selecting other proxy, like when the proxy times out.

What do you think ?

thanks!

Here is the configuration I use: random_chain chain_len = 1

tcp_read_time_out 15000 tcp_connect_time_out 8000

[ProxyList]

socks4 ip1 port1 socks4 ip2 port2 socks4 ip3 port3

:~ $ curl -vvvvvv --socks4 x.x.x.x:yyyy ipinfo.io

$ proxychains4 -f /etc/proxychains4.conf curl http://ipinfo.io [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.16 [proxychains] Random chain ... x.x.x.x:yyyy ... 34.117.59.81:80 <--socket error or timeout! curl: (7) Couldn't connect to server

rofl0r commented 2 years ago

so you're saying this happens when the connection estasblishment step to the proxy works, and it then times out connecting to the next hop (whether that be another proxy or the target)?

jeremyp3 commented 2 years ago

Yes that's exactly it.

rofl0r commented 2 years ago

ok, so in order to make it behave like you want to we'd basically have to restore proxychains state to what it was before the last connection step, which could be non-trivial. i can see that what you suggest could improve user experience, otoh the behaviour of proxychains during the last 20 years is well-established and identical to what you experience when e.g. calling curl directly with a proxy option, so i think most random_chain users already have smoe sort of retry-loop in their scripts. anyway if someone wants to implement this and it's not to intrusive i think we can make the change.