Continued inability to get Socks5 Proxy to connect since 4.1.9.1 (Nordvpn)

[Aerasyn]

qBittorrent & operating system versions

qBittorent 4.4.0 Windows 11 (10.0.22xxx) (10 previosuly as well with every version since qB v4.1.9.1)

What is the problem?

I cannot get any version of qBittorrent to connect to a Nordvpn socks5 Proxy since version 4.1.9.1. I have been testing them ever since. I've been told multiple times that the issue has been fixed but everytime I still don't see a connection result. In the log it reports "socks5 proxy error" over and over until i close program or disable proxy in settings.

Steps to reproduce

Use any version of qbittorrent past 4.1.9.1 and try to use Nordvpn sock5 proxy address with authentication.

Additional context

At this point I don't really care since 4.1.9.1 still allows it to work, but I want to report it whenever there is a significant revision to qBittorrent

Log(s) & preferences file(s)

[adrian5]

I get this too sometimes, using a different provider. I always assumed this was some component of the connection (e.g. the proxy) timing out.

[Aerasyn]

I always test between a few available nord servers and between each new version and then back to 4.1.9.1. 4.1.9.1 is the only one that doesn't give the error. 4.1.9.1 doesnt have the same visible proxy logging like the later ones but i can always get that version to connect if not the first time. This error on later versions is 100% consistant in my case. I am always forced to revert back to the older version to retain proxy usage.

[adrian5]

In my case I never noticed any apparent loss in function (I could be wrong), but my proxy is non-authenticating.

Fresh on 4.4.0:

[ghost]

How do you know that it works in 4.1.9.1. Did you check for IP leak? Because those versions will leak IP if proxy failed.

[Aerasyn]

My actual ip address shows up in the log first before i start a torrent then when it starts the metadata search for a magnet file it will show the new ip address for the nordserver in the log. I never start the torrent unless that new ip address appears. Trial and error my friend. Been doing it for a couple years since 4.1.9.1 came out. If the new ip address doesnt show then I get friendly neighborhood DMC notices. I just restart the program once or twice because sometimes it doesnt show up the first time, or i have to give it a minute to load. Can never get it to get that far on any version after 4.1.9.1. Always the error above no matter how many times i restart. Also, I only use magnet files instead of torrent files so that the metadata grab initiates the nord server ip address and confirms for me.

Oh, and yeah, I use software called glasswire that confirms the qbittorrent traffic is going through Nord Servers.

[sledgehammer999]

Maybe @arvidn can test this?

[arvidn]

@sledgehammer999 which libtorrent version does that translate to? the last working one?

[sledgehammer999]

@arvidn sorry for not mentioning it already. The issue appears with libtorrent 2.0.5+gitd0f7a09adb

[thalieht]

the last working one?

qBittorrent 4.1.9 uses libtorrent RC_1_1 909211888e7b11a67146fef117324c6a6298d46e (judging by 4.1.9 release date and qBt almost always using the latest available commit of the stable libtorrent branch at the time of release).

[sledgehammer999]

@arvidn to summarise: The latest version of qbt is 4.4.0 and shows the above proxy problem. This version uses libtorrent 2.0.5+gitd0f7a09adb. According to the reporting user the last known working version of qbt is 4.1.9 which uses libtorrent 1.1.13+git909211888e.

[spongebob128]

Same here with respect to the btguard.com proxy. Has not worked for all versions since 4.1.9.1.

[ghost]

Did you ensure that qbit is listening on an unused port?

Edit: after further testing I'm inclined to think that nord is junk. It keeps giving me this error intermittently no matter what I do but some other unnamed VPN is completely fine.

[Aerasyn]

Yes, the log reports that a unused port is listening actively when the errors occur on any version after 4.1.9.1 Not sure how to respond to the nord is junk comment. Was working fine up till QB moved past 4.1.9.1

[ghost]

Sorry for the unsolicited opinion but it's running flawlessly on my self hosted socks server ever since I dropped nord. Three cheers for microsocks!

[corobin]

I have the same problem. I'm not on nord, but PIA.

I did some digging and found #7734. pulling on the threads leads to the bottom of #12583 where FranciscoPombal says that all known issues have been solved and if you still have problems please open a new issue.

Searching open issues for SOCKS5 shows several reports of it not working, e.g. #14636, #14345 (also says since 4.1.9.1), #14532, #17460, #16208

My experience is similar to most of yours. This is what I have:

Almost all the time, qBt fails to make any connections at all. but every once in a blue moon it would be able to connect and download the torrent, but the download speed has slowed to a crawl lately (maybe #16359?) even though the proxy continues to support much faster speeds. disabling the SOCKS proxy makes the problem go away instantly.

I also noticed, that if you do not "use proxy only for torrents" (refer #11457), then the failure to connect to torrents also correlates a failure of the automatic update check. this appears to make sense: if qBt is using the proxy for the entire application, and fails to connect through the proxy, then all internet activity throughout the application will be disrupted, not just torrents.

My current version is 4.4.3.1 x64 qt5 libtorrent 2 on Win 10, but as noted the issue has persisted for many versions already.

Hope this adds some useful information to help with investigating.

edit: after some further testing, it looks like using the libtorrent 1.2 variant of the latest qbt version (4.4.3.1) does not fix the issue. but deluge 2.1.1 even with libtorrent 2 is able to reliably make connections on the same computer

[sonalys]

Maybe add ability to not use proxy for RSS connection? We already have an option to use proxy on torrents or not.

Edit: I found out the bug happens when using very low upload threshold, like 1 kbps. When I removed this limit it stopped happening for me.

[h-2]

For me, SOCKS5 + current qbittorrent + NordVPN seems to work.

[Aerasyn]

Well, the VPN itself will always work. My issue is with the Nord Socks5 servers alone. To this day I've only been able to get them to connect on QB 4.1.9.1 and no version since with only the Socks5 servers from Nord. Are you saying that you went into QB setting and did the options for nord Socks5 servers and authentication and you were able to get a connection that showed a different IP address than your own in the execution logs on QB? No big deal for me. i've always been happy to stay on 4.1.9.1, it just seems a shame that it never works and hasn't for years now and I always get some half interest in here about looking into it but it never works on any version I install, so I always go back to 4.1.9.1. -shrug- Been raising this issue for years with no traction or change. Pretty used to it by now ;)

[h-2]

Are you saying that you went into QB setting and did the options for nord Socks5 servers and authentication and you were able to get a connection that showed a different IP address than your own in the execution logs on QB?

Yep. I run qB 4.5.5. I set up the SOCKS5 as described in the NordVPN FAQ, and I verified with ipleak that the proxy IP is exposed. Note, that as with my previous Proxy, UDP connections do not seem to work, i.e. no DHT and no UDP trackers. Especially the latter can be a problem, so make sure to add some http trackers.

edit: DHT does seem to work! I hope it still goes through the proxy, but monitoring of outgoing connections seems to confirm that it does. [no connections going anywhere but the NordVPN subnet]

[Masong19hippows]

Has there been any development on this? I am coming across the same issue with the current stable release. All udp trackers give "permissions denied" in the GUI and the logs show the same "end of file" error that the original author got. After extensive research, it seems this problem keeps popping up with created issues almost every release and then the issue goes stale or the solution is to not use Socks5 protocol.

I compiled from source yesterday and have tried multiple socks5 proxy servers including some of the most popular like microsocks and danted.

[HanabishiRecca]

Has there been any development on this? I am coming across the same issue with the current stable release.

What libtorrent version do you use? This issue should have been fixed in libtorrent 2.0.8/2.0.9 afaik. See arvidn/libtorrent#6986 and arvidn/libtorrent#6987.

[Masong19hippows]

What libtorrent version do you use? This issue should have been fixed in libtorrent 2.0.8/2.0.9 afaik. See arvidn/libtorrent#6986 and arvidn/libtorrent#6987.

I tested with the appImage of the nightly build of qbittorrent which claims to use libtorrent 2.0.10. I have also tested with the appImage from the same nightly build with libtorrent 1.2.19. Also tested with the latest stable package from apt repositories (I think it was qbittorrent 4.5)

All 3 of those had the exact same behavior with udp trackers where it would show "permissions denied" in the webgui and an error about "end of file" in the logs.

[arvidn]

in order to understand why socks5 isn't working, please capture a wireshark dump (ideally filtered to only include traffic to the proxy itself).

[Masong19hippows]

I just recompiled qbittorrent 4.6.5 with libtorrent 2.0.11.0 and tested it with this build. I also am using danted as the socks5 server for simplicity. Packet capture is below, running on the qbittorrent host and filtered for the socks5 proxy port.

https://www.dropbox.com/scl/fi/j35dw6nhvi5w36dga02j8/capture.pcap?rlkey=xaypadmlqtmk457p3iwkom4b3&st=azdol669&dl=0

[Masong19hippows]

@arvidn I beileve I narrowed down the issue more. It seems like its only happening whenever the socks5 server is not on the same host as the qbittorrent host. Anything entered into the host section that is not pointing to localhost immediately gives a permissions denied error on all udp trackers. I have tried the fqdn, hostname, and ip address. I have verified that its not a network issue as I am able to curl through the proxy and use it with other apps.

I copied my dante-server config that's currently running on a different system and put it on the same host that is running qbittorrent, and it works just fine with the exact same settings in qbittorrent. This works with localhost, the loopback ip, and the real ip address of the qbittorrent host.

All I did was change the ip address in the "host" section of the socks5 client config in qbittorrent to point towards my other machine rather than the qbittorrent host, and udp trackers stopped working.

I then routed a local port on the qbittorrent host to point to the socks5 server on a diffrent machine using socat. Command that I used on the qbittorrent host is below. I have verified this setup works using curl.

sudo socat TCP-LISTEN:1081,fork TCP:192.168.1.2:1081

I still got the permissions denied error. It seems that there is something preventing udp outbound socks5 connections from working either in libtorrent or in qbittorrent. All of this was tested with a locally compiled libtorrent version 2.0.11.0 and qbittorrent 4.6.5.

[arvidn]

This is the SOCKS-5 specification. This is one of the interactions I see in the dump:

client -> 05 01 00 (version: 5 authentication methods supported [0x00])
server <- 05 00 (version: 5, select authentication method 0x00)
client -> 05 01 00 03 13 74 72 61  63 6b 65 72 2e 62 61 72 (version: 5 CONNECT "tracker.baravik.org")
server <- 05 04 00 03 13 74 72 61  63 6b 65 72 2e 62 61 72 (version: 5 HOST_UNREACHABLE "tracker.baravik.org")

Is that the error you see too? If so, it looks like the proxy is reporting it.

[Masong19hippows]

For the authentication, this makes sense as I disabled authentication for the test.

For the unreachable error, I see that error along with a couple of others for different domains. This is to be expected because this is not a test torrent that I used. Those trackers were most likely having some issue at the time.

It also shows the "Connect" protocol being used, which indicates that this was an http tracker that was having issues. I still have that torrent paused at the moment, so I was able to verify that this was an http tracker and it did have a "no route to host" error in the webgui. I also set the proxy setting to none and restarted the torrent, and the tracker still didn't work but udp trackers did. This should be unrelated to the issue presented.

I haven't had time to do this yet, but I want to get a packet capture of running the socks5 server on the qbittorrent host vs running on a different host and compare them.

[Masong19hippows]

So, I just got it to work with a socks proxy running on a different host. I decided to start clear and wipe the qbittorrent folder in ~/.local/share/data and in ~/.config/. After I set everything back up, udp trackers worked just fine through the proxy with no errors. This was using the latest app image from the nightly build. Maybe changing versions so many times messed something up in the config files? No idea

[h-2]

I have a vanilla setup here on Ubuntu 22.04. I am using NordVPN SOCKS5 with authentication.

I still don't get connections to UDP trackers. They always time out.

In the past, this has never worked for me. Over years of different qBittorrents being setup fresh, on different client operating systems and with different SOCKS proxy providers. So I am quite surprised to hear that @Masong19hippows got it to work. Are you absolutely certain? Can you verify that your connection really goes through the proxy?

[Masong19hippows]

@h-2 I was able to verify using tcpdump. I used the following dante-server config for testing. My actual socks5 proxy is using this because its the only socks5 server that allows fwmarks for each user.

user.privileged: root
user.unprivileged: nobody
logoutput: /var/log/sockd.log

internal: 0.0.0.0 port=1081
external: 192.168.1.2

socksmethod: none
clientmethod: none

client pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    log: connect disconnect error
}

socks pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    log: connect disconnect error
}

Here is my settings for qbittorrent. My errors were always a "permissions denied" in the webgui and a "end of file" error in the logs. If you have something different than that, then it might be a different issue. Might try testing with a linux iso and a socks5 server that you can control locally, like dante.

[pxlnght]

I was having a similar issue with the linuxserver/qbittorrent docker image. After reading @Masong19hippows 's post, I deleted my qBitorrent.conf and setup my proxy again... works fine now. Very odd.

[Haerbin23456]

Same here with Sing-box. But I can't solve it by simply deleting qBittorrent.ini. Using qBittorrent Enhanced Edition.

What's more, it actually worked well at first, but suddenly all of them showed timed out, then permission denied. Really weird.

[Haerbin23456]

Now it worked fine with me after another reboot wtf

Updated: Now I don't think qBittorrent.ini is really related.

[Haerbin23456]

Finally I have found a stable way to reproduce the issue.

(I'm using libtorrent 2.0.10, so this comment may not be helpful for those using libtorrent 1.x.xx.)

TL;DR: Just open qBittorrent before turning on your socks5-server (e.g. I'm using sing-box). This way udp trackers would show "permission denied" consistently, even after socks5-server starts. However http trackers do resume after the socks5-server starts.

I have my socks5-server (sing-box) started at 127.0.0.1:20122. If I start sing-box before opening qBittorrent, udp trackers would work fine (probably, when you have only one udp tracker), and sing-box would show a log like this:

+0800 2024-09-02 13:49:14 INFO [977073719 0ms] inbound/mixed[0]: inbound connection from 127.0.0.1:3825
+0800 2024-09-02 13:49:14 INFO [977073719 0ms] inbound/mixed[0]: inbound packet connection to 0.0.0.0:0
+0800 2024-09-02 13:49:14 DEBUG [977073719 29ms] router: sniffed packet protocol: bittorrent
+0800 2024-09-02 13:49:14 DEBUG [977073719 29ms] dns: lookup domain tracker.opentrackr.org
+0800 2024-09-02 13:49:14 DEBUG [977073719 29ms] dns: match[1] clash_mode=direct => local-dns
+0800 2024-09-02 13:49:14 DEBUG [977073719 37ms] dns: exchanged tracker.opentrackr.org NOERROR 31
+0800 2024-09-02 13:49:14 DEBUG [977073719 37ms] dns: exchanged tracker.opentrackr.org NOERROR 99
+0800 2024-09-02 13:49:14 INFO [977073719 37ms] dns: exchanged tracker.opentrackr.org A tracker.opentrackr.org. 31 IN A 93.158.213.92
+0800 2024-09-02 13:49:14 INFO [977073719 37ms] dns: exchanged tracker.opentrackr.org SOA opentrackr.org. 99 IN SOA ns0.transip.net. hostmaster.transip.nl. 2021091701 86400 1800 2419200 300
+0800 2024-09-02 13:49:14 INFO [977073719 38ms] dns: lookup succeed for tracker.opentrackr.org: 93.158.213.92
+0800 2024-09-02 13:49:14 DEBUG [977073719 38ms] dns: resolved [93.158.213.92]
+0800 2024-09-02 13:49:14 DEBUG [977073719 38ms] router: match[1] clash_mode=direct => direct
+0800 2024-09-02 13:49:14 INFO [977073719 38ms] outbound/direct[direct]: outbound packet connection

(But I wonder what's 0.0.0.0:0 here. And there are errors in qBittorrent says SOCKS5 proxy error. Address: 127.0.0.1:20122. Message: "指定的网络名格式无效。(translate: The specified network name format is invalid.)".

If I open qBittorrent first, after that I turn on sing-box, udp trackers would all be broken, and sing-box would show a log like this instead:

+0800 2024-09-02 13:16:49 INFO [3568361656 0ms] inbound/mixed[0]: inbound connection from 127.0.0.1:2645
+0800 2024-09-02 13:16:49 INFO [3568361656 0ms] inbound/mixed[0]: inbound packet connection to 0.0.0.0:0
+0800 2024-09-02 13:16:49 DEBUG [3568361656 301ms] router: match[1] clash_mode=direct => direct
+0800 2024-09-02 13:16:49 INFO [3568361656 301ms] outbound/direct[direct]: outbound packet connection
+0800 2024-09-02 13:16:49 DEBUG [3568361656 315ms] inbound/mixed[0]: connection closed: process connection from 127.0.0.1:2645: upload: write udp [::]:62971->:0: wsasendto: The requested address is not valid in its context. | download: raw-read udp [::]:62971: use of closed network connection | writeto tcp 127.0.0.1:20122->127.0.0.1:2645: read tcp 127.0.0.1:20122->127.0.0.1:2645: use of closed network connection

And an error SOCKS5 proxy error. Address: 127.0.0.1:20122. Message: "End of file". shows up in qBittorrent log.

I also tried:

1. Start sing-box before opening qBittorrent.
2. Then shut down sing-box for a while.
3. Start sing-box again.
4. Force reannounce.

This time it also shows "permission denied" and shows the same log.

[Haerbin23456]

There are more I found out. If I only have only one udp tracker, and it's already in the qBittorrent before I open the qBittorrent, the behavior is described above. However if I add one udp tracker after qBittorrent started, it will "permission denied". After a restart of qBittorrent it works fine. If I have two udp trackers altogether and restart, only the first udp tracker works. If I have very very many udp trackers, none of them would work at most time, no matter what i do.

[Haerbin23456]

I have the same problem. I'm not on nord, but PIA.

I did some digging and found #7734. pulling on the threads leads to the bottom of #12583 where FranciscoPombal says that all known issues have been solved and if you still have problems please open a new issue.

Searching open issues for SOCKS5 shows several reports of it not working, e.g. #14636, #14345 (also says since 4.1.9.1), #14532, #17460, #16208

My experience is similar to most of yours. This is what I have:

Almost all the time, qBt fails to make any connections at all. but every once in a blue moon it would be able to connect and download the torrent, but the download speed has slowed to a crawl lately (maybe #16359?) even though the proxy continues to support much faster speeds. disabling the SOCKS proxy makes the problem go away instantly.

I also noticed, that if you do not "use proxy only for torrents" (refer #11457), then the failure to connect to torrents also correlates a failure of the automatic update check. this appears to make sense: if qBt is using the proxy for the entire application, and fails to connect through the proxy, then all internet activity throughout the application will be disrupted, not just torrents.

My current version is 4.4.3.1 x64 qt5 libtorrent 2 on Win 10, but as noted the issue has persisted for many versions already.

Hope this adds some useful information to help with investigating.

edit: after some further testing, it looks like using the libtorrent 1.2 variant of the latest qbt version (4.4.3.1) does not fix the issue. but deluge 2.1.1 even with libtorrent 2 is able to reliably make connections on the same computer

I tried deluge (Windows, libtorrent 2.0.6.0), permission denied. I believe it's a libtorrent bug. @arvidn

[Masong19hippows]

@Haerbin23456 this is really intresting behavior because during my testing, I restarted qbittorrent multiple times while the proxy server stayed active. I was actually manually running the command in a terminal with

qbitttorrent-nox --webui-port=8001

And so when I tested it and found that it didn't work, I would do Ctrl+c on the command above so that I could access the terminal again and then do more debugging. I wonder if this is a Linux vs Windows difference as I was using Ubuntu 22.04 server edition, and it looks like you are using windows (please correct me if I'm wrong). This would also make sense on why deleting the config file didn't fix the issue for you, because the other user that this worked with was also using a .conf file, Wich indicates that they were using Linux.

So, I think there are two separate issues here (one on Linux and one on windows) and that's why it's been so hard to track it down. It seems like they both might be caused by different things, but present the same symptoms.

[h-2]

My errors were always a "permissions denied" in the webgui and a "end of file" error in the logs. If you have something different than that, then it might be a different issue.

I was having a similar issue with the linuxserver/qbittorrent docker image. After reading @Masong19hippows 's post, I deleted my qBitorrent.conf and setup my proxy again... works fine now. Very odd.

I have re-setup a fresh install of qbittorrent (this time the -nox flavor on a FreeBSD server) and I am getting permission denied on UDP trackers, i.e. they still don't work.

[Masong19hippows]

@h-2 have you tried compl clearing the config folder and the share folder, and then setting it up again? If so, can you try spinning up a Socks5 proxy via danted on the same machine that is running qbittorrent, and seeing if that works?

[Haerbin23456]

@Haerbin23456 this is really intresting behavior because during my testing, I restarted qbittorrent multiple times while the proxy server stayed active. I was actually manually running the command in a terminal with

qbitttorrent-nox --webui-port=8001

And so when I tested it and found that it didn't work, I would do Ctrl+c on the command above so that I could access the terminal again and then do more debugging. I wonder if this is a Linux vs Windows difference as I was using Ubuntu 22.04 server edition, and it looks like you are using windows (please correct me if I'm wrong). This would also make sense on why deleting the config file didn't fix the issue for you, because the other user that this worked with was also using a .conf file, Wich indicates that they were using Linux.

So, I think there are two separate issues here (one on Linux and one on windows) and that's why it's been so hard to track it down. It seems like they both might be caused by different things, but present the same symptoms.

Well,I tried the Dante server running on WSL, and the upd trackers never get to work. It says:

danted[47110]: info: block(1): udp/udpassociate -: 172.20.0.1.37522 172.20.12.183.35640 -> 0.0.0.0.0 1c.premierzal.ru.6969: could not resolve target address 1c.premierzal.ru.6969: Temporary failure in name resolution

The actual url is udp://1c.premierzal.ru:6969/announce. I checked the packet in wireshark. The host and port was in fact passed correctly to Dante.

[Haerbin23456]

If I open qBittorrent first, after that I turn on sing-box, udp trackers would all be broken, and sing-box would show a log like this instead:

+0800 2024-09-02 13:16:49 INFO [3568361656 0ms] inbound/mixed[0]: inbound connection from 127.0.0.1:2645
+0800 2024-09-02 13:16:49 INFO [3568361656 0ms] inbound/mixed[0]: inbound packet connection to 0.0.0.0:0
+0800 2024-09-02 13:16:49 DEBUG [3568361656 301ms] router: match[1] clash_mode=direct => direct
+0800 2024-09-02 13:16:49 INFO [3568361656 301ms] outbound/direct[direct]: outbound packet connection
+0800 2024-09-02 13:16:49 DEBUG [3568361656 315ms] inbound/mixed[0]: connection closed: process connection from 127.0.0.1:2645: upload: write udp [::]:62971->:0: wsasendto: The requested address is not valid in its context. | download: raw-read udp [::]:62971: use of closed network connection | writeto tcp 127.0.0.1:20122->127.0.0.1:2645: read tcp 127.0.0.1:20122->127.0.0.1:2645: use of closed network connection

And an error SOCKS5 proxy error. Address: 127.0.0.1:20122. Message: "End of file". shows up in qBittorrent log.

Seems that the udp packet which should be following wasn't there in this case. (Left: expected behavior. Right: premission denied + End of file behavior. Using sing-box) Wireshark file

[Masong19hippows]

@Haerbin23456 The wsl issue looks like its unrelated. It doesn't seem that WSL was able to resolve those addresses at the time.

can you please link the config you are using for sing-box? I tried to replicate this using windows, but I got different behavior. I got a permissions denied error when I stopped my socks5 proxy, but it continued just fine after I started it again. However, I am running the socks5 server on a different host than the windows machine. I want to see if running it on the same host like you causes the issue.

[Haerbin23456]

@Masong19hippows config:

{
  "log": {
    "level": "trace",
    "timestamp": true
  },
  "inbounds": [
    {
      "type": "mixed",
      "listen": "::",
      "listen_port": 11451,
      "sniff": true,
      "domain_strategy": "prefer_ipv4"
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "dns",
      "tag": "dns-out"
    }
  ],
  "route": {
    "rules": [
      {
        "protocol": "dns",
        "port": 53,
        "outbound": "dns-out"
      }
    ],
    "final": "direct",
    "auto_detect_interface": true
  },
  "dns": {
    "servers": [
      {
        "tag": "remote-dns",
        "address": "8.8.8.8",
        "detour": "direct"
      },
      {
        "tag": "local-dns",
        "address": "223.5.5.5",
        "detour": "direct"
      }
    ],
    "final": "local-dns",
    "strategy": "ipv4_only"
  }
}

By default it uses a China DNS resolver, because Google DNS (8.8.8.8) is blocked in China XD. If you can connect to Google DNS you should change the dns > final value to "remote-dns".

[Haerbin23456]

Emmmm... It seems that it's actually sing-box bug. Sing-box closed the connection too early, so libttorrent can't send the udp packets. If the bug is fixed on sing-box side, perhaps everything would work fine.