Upgrading connection from Global direct to Local direct


I have a use case where I would prefer local direct tcp connections over the global counterpart. Referring to the existing discussions in link 1 and link 2, I understand that it is already prioritized that way in Syncthing. However, it is done only until a connection has been established. After that we have to apply the following hack:

Will a background connection upgrade routine help here? (Just like we have one for upgrading a relay connection to a direct one)

It could. Currently, there are two prioritization / sorting steps. One is in the discovery service. It prioritizes local discovery over global and returns lookup results sorted this way (local address before global ones). The second is in the connection service. It prioritizes per protocol, tcp:// over relay:// mostly and will attempt to switch from a connection type with a worse priority to a connection type with a better priority. However, at that stage both the locally and globally found addresses are tcp:// and it sees no reason to prefer one over the other (apart from the order it tried them in, which was the order returned by discovery).

The connection service could be amended to also take into account the order received in the connection lookup. It could have a more fine grained priority that is a tuple (protocol priority, discovery priority) and periodically retry connections with better discovery priority that otherwise have the same protocol priority.

Then couldn’t it prioritize same LAN subnet IP’s over other ones (and local udp over all others) ?

Why does this matter though, all self respecting routers will already provide same performance in this case.

I don’t understand : do you think about thing called NAT loopback or that LAN to real WAN connections must be assumed better or equal quality than LAN to LAN ?

Routing through a router using its public IP should not be much worse than routing through lan ips it gives to someone.

Yes, you’re right : “not much worse” and I don’t feel it’s time to worry about tiny gain in performances. I missed the point of this question. At the time I thought all exchanges between local devices use UDP. IIUC now, only discovery use UDP.

Sorry to have bumped this post out of Morpheus arms.

Have a good day Audrius


I have 2 computers sitting next to eachother on the same switch but they are connected to internet via a socks proxy.

For whatever reason they prefer their public IP (through the proxy) before their local IP.
When the connection to the proxy server is cut (e.g. proxy config is removed at one computer) they use the local connection.

When they use public IPs this means 500kB/s instead of 20MB/s on local connection.

I would not call this difference tiny.

Also this brings a lot of waste load to the proxy and the connection to it. This blocks capacity which is better used for real up-link connections. Same is valid if there is no proxy but a normal router/NAT device.

running v0.14.44 win64

But this is down to your configuration which forces syncthing to use the proxy, which kills local discovery most likely. You can try to hard code addresses yourself instead of dynamic discovery.

…which kills local discovery most likely.

don,t think so.
Like I saied “proxy config is removed at ONE computer” (but not on the other) make both to find each other on local connection and use them for data transfer. So local discovery is working but the local IP is just not used if both have another connection

your configuration which forces syncthing to use the proxy,

Yes, because I need global discovery as well as data transfer to computers outside the LAN. Also both computers are mostly but not always conneted to the same switch.
So disabling the proxy is no real option.

however, I think I will play around with hard code addresses.

If you have a proxy set all connections are made through the proxy. Even to addresses discovered through local discovery, which may or may not work.

When you disable proxying connections are made directly.

Even with proxying enabled, direct connections from other devices are accepted.

In short, with proxying enabled all connections will go via the proxy. This is what you asked for.

There may be an environment variable that defines addresses that should not go through the proxy, which we may or may not follow. I don’t know and I can’t check right now.

The env var for excluding proxying is called no_proxy

1 Like


no_proxy worked.

Thank you.