I don't understand.

The hostname one should have been hostlocal:8080, but is:
curl: (7) Can't complete SOCKS5 connection to localhost:29804. (4)

Why "hostlocal" ? And did it really say 29804 when you connected to 2903? That seems really weird.

The IPv6 should be [2001:0DB8:AC10:FE00:0000:0000:0000:0000]:8080, but is:

Sorry, but why/how should it be that? And is this perhaps related to https://curl.haxx.se/docs/knownbugs.html#SOCKS_proxy_not_working_via_IPv6 ?

With the codes like 05 00 05 04 00 03 09 68 6f 73 74 6c 6f 63 61 6c 1f 90 I use socat to pretend to curl that it is talking to a socks5 proxy, which in this case is negotiating for no authorization and denies the connection with error code 4 to the server detailed in the rest of the reply. The 68 6f 73 74 6c 6f 63 61 6c is the hostname which is "hostlocal" in hex. I should probably have chosen a different hostname, but I was lazy by just moving octets around in testing. The two following octets defining the port are equally made up just for testing (I picked port 8080 just because). So, no real socks5 proxy is involved, I am just simulating what a socks5 would do to observe what the client does for testing.

Regarding port, just look at the source, for IPv6 its perhaps clearest: https://github.com/curl/curl/blob/master/lib/socks.c#L689
For all three types it chooses the 9th and 10th octet to calculate the port. That is correct for IPv4, but incorrect for hostname (logically, that can't be a fixed number given that the hostname is variable length and the port follows after the hostname) and for IPv6 the 9th and 10th octet are in the middle of the IPv6 number itself, so that logically can't really be producing the right port either.

These are all just display issues in error messages – no effect on successful runs and hence also unrelated to the known bugs – through as far as I know socks4 doesn't support IPv6 – one of the reasons for socks5…

I hope that makes it slightly clearer. Sorry for not being more explicit – having just recently read the relevant RFCs makes this all super obvious, but in a few days I would probably haven't understood myself either. ;)

@DonKult Except not using the returned hostname, the incomplete response and invalid port issues should be fixed by the 3 commits mentioned above. Please try the current master. I did not fix the hostname part, because I think validating that the server did not return a malicious combination of hostname and its length is not worth the effort for this error case. So curl will display the requested hostname instead of the returned hostname in this error case.

(not tested the commits yet)
The thing with the hostname is that the hostname displayed is the one used in the request, not the hostname the server returned. Most of the time it will be the same, but lets imagine your socks-proxy does support SRV records, so that you will request example.org and e.g. (via SRV lookup) get back foobar.example.net. Nothing malicious about it, but if its worth to fix it or not is your call of course.

In any case it should probably return both the requested and the returned IP or hostname. That would probably be the most clearest solution.

@DonKult I just pushed a series of commits to the master branch in order to streamline the verbose debug and error messages during the SOCKS4 and SOCKS5 connection sequences. At least in case of an error in the final phase of the connection sequence, the destination (IPv4, hostname or IPv6) returned by the proxy server will be displayed. Please check if the issue can now be considered fixed.

Presumably fixed, closing