Could not set proxy address: Try again (socks5) about rtorrent

[kannibalox]

Okay, so correct me if I'm wrong:

1. This means that trying to use a SOCK5 proxy for peer connections has never worked in rtorrent?

2. That many novices (like myself) incorrectly assumed that setting `network.http.proxy_address.set` with a SOCK5 proxy automatically will proxy it for peer connections as well?

There's never been anything in the code to support it, I'm pretty certain about that. As for point 2, it could stand to be documented better (it's not merged back into the main rtorrent-docs repo yet, but I've added some here: https://kannibalox.github.io/rtorrent-docs/cmd-ref.html#term-network.proxy_address), but at the same time it is specifically named as an HTTP proxy setting.

The elephant in the room here is a VPN, which if you're really concerned about security is what I would recommend over any proxy settings in any torrent client.

[kannibalox]

The peer proxy (network.proxy_address) is handled internally, as opposed to the announce proxy (network.proxy_address), which is just passed straight to libcurl. The peer proxy needs to be either a hostname or IP address, with an option port. If the port is left out, it will assume it's port 80. The proxy needs to be able to handle HTTP 1.0 CONNECT calls.

The following examples worked for me in 0.9.8:

example.com
example.com:8080
1.1.1.1
1.1.1.1:8080

One thing to note about the command is that it resolves any hostnames during the set itself. If the DNS lookup doesn't succeed, the command will fail with Could not set proxy address: Name or service not known.

$ rtxmlrpc network.proxy_address.set '' fake.example.com:80
ERROR:pyrosimple.scripts.rtxmlrpc.RtorrentXmlRpc:While calling network.proxy_address.set('', 'fake.example.com:80') via <RTorrentProxy via xml for localhost:9998>: <RpcError -503: 'Could not set proxy address: Name or service not known.'>

[kannibalox]

My apologies, I explained a bunch of stuff but never addressed the specific error you're getting. It means that the DNS server you're using returned an error (as opposed to the example I provided, where it was simply unable to resolve the domain). The reason it's saying "try again" is because it's a specific type of error that indicates the DNS server might be able to resolve things correctly later.

You could try switching DNS servers to something common like 8.8.8.8 or 1.1.1.1 to see if that helps, and checking your network configuration to ensure there's nothing else that could be interfering with DNS lookups to the specific proxy domain you're trying to use.

[ToshY]

hey @kannibalox 👋

No reason for apologies, I'm glad someone took the effort to take a look at this 🙂. I will try to see if I can figure some things out with the information you've provided.

Think I forgot to mention that I'm running this inside a docker container. Normally that shouldn't be a problem, but I'll state it just in case.

[ToshY]

hey @kannibalox 👋

I've been trying some stuff out and I'll respond to some of your earlier remarks.

rtxmlrpc network.proxy_address.set '' fake.example.com:80

I don't have rtxmlrpc in my container, but I've figured out I can set the option with rtorrent directly:

rtorrent -o "network.proxy_address.set=socks5h://<username>:<password>@<host>:1080"

Which gives again rtorrent: Failed to parse command line option: Could not set proxy address: Try again.. I'm not able to get more verbose output than this though, not sure if that's possible?

The proxy needs to be able to handle HTTP 1.0 CONNECT calls.

I've tested the following (I'm not sure if that's what you refer too)

curl --proxy1.0 socks5h://<username>:<password>@<host>:1080 http://ipleak.net

Also tried adding -x CONNECT, which resolved but returned 405 in the example above (not sure if this adds any additional information for you).

The reason it's saying "try again" is because it's a specific type of error that indicates the DNS server might be able to resolve things correctly later.

Okay if that's the case, how would I be able to reproduce the Try again error message outside of rtorrent to verify that what you state is indeed causing the problem?

---

Maybe if I understood what the code actually does (and the related rak/address_info.h), I would be able to understand why it either fails or how to create a reproducable case.

 if ((err = rak::address_info::get_address_info(buf, PF_INET, SOCK_STREAM, &ai)) != 0)
    throw torrent::input_error("Could not set proxy address: " + std::string(rak::address_info::strerror(err)) + ".");

[kannibalox]

rtorrent -o "network.proxy_address.set=socks5h://<username>:<password>@<host>:1080"

Which gives again rtorrent: Failed to parse command line option: Could not set proxy address: Try again.. I'm not able to get more verbose output than this though, not sure if that's possible?

The network.proxy_address, regardless of how it's called, expects only a hostname/IP and an optional port.

rtorrent -o "network.proxy_address.set=<host>:1080"

That means that there's no username/password or protocol you can set, and it only supports sending HTTP 1.0 CONNECT calls (i.e. no SOCKS or HTTPS). This can be seen over in libtorrent: https://github.com/rakshasa/libtorrent/blob/91f8cf4b0358d9b4480079ca7798fa7d9aec76b5/src/protocol/handshake.cc#L946. I'm pretty certain including the protocol/username/password is what's causing errors for DNS.

To test the proxy itself with curl, you can just leave off the protocol there as well:

curl --proxy1.0 <host>:1080 http://ipleak.net

Maybe if I understood what the code actually does (and the related rak/address_info.h), I would be able to understand why it either fails or how to create a reproducable case.

 if ((err = rak::address_info::get_address_info(buf, PF_INET, SOCK_STREAM, &ai)) != 0)
    throw torrent::input_error("Could not set proxy address: " + std::string(rak::address_info::strerror(err)) + ".");

Yep, this is where the error is coming from. After a little redirection via the rak:: namespace, it'll turn out it's basically doing getaddrinfo() and returning the result of gai_strerror() if it fails: https://linux.die.net/man/3/getaddrinfo. If you send your DNS server a query for the literal string socks5h://<username>:<password>@<host>, it would certainly not be able to process it correctly.

[ToshY]

hey @kannibalox 👋

I've tried using <host>:1080 like you suggested by putting network.proxy_address.set = <host>:1080 in my rtorrent config. When restarting it, I don't see the error anymore, but upon testing it still does not use the actual proxy for peer connections (connected to same torrent, from anoter client (uTorrent) I still see original/non-proxy IP).

That means that there's no username/password or protocol you can set, and it only supports sending HTTP 1.0 CONNECT calls (i.e. no SOCKS or HTTPS). This can be seen over in libtorrent: https://github.com/rakshasa/libtorrent/blob/91f8cf4b0358d9b4480079ca7798fa7d9aec76b5/src/protocol/handshake.cc#L946. I'm pretty certain including the protocol/username/password is what's causing errors for DNS.

Okay, so correct me if I'm wrong:

1. This means that trying to use a SOCK5 proxy for peer connections has never worked in rtorrent?
2. That many novices (like myself) incorrectly assumed that setting network.http.proxy_address.set with a SOCK5 proxy automatically will proxy it for peer connections as well?

---

Sidenotes:

• In hinsight I've stumbled upon your comment (dating back to 2019) in issue #105 stating the exact same (disregarding the fact that nowadays network.http.proxy_address does support SOCKS5).
• I've also tried setting up SOCK5 proxy in uTorrent, which was not only easier (due to the GUI), but also worked instantly without any issues (redacted host/credentials in screenshot).