Running 2 instances of Syncthing on 1 server

[lucidfox]

I'm trying to run a second instance of Syncthing on a server (installed on another domain). I set the sync port in Cloudron to a non-standard port '22846' while setting up the second instance, but it just isn't able to connect to other devices. Is this because other ports apart from '22000' are blocked? In the app config page it says 'Port over which syncthing will exchange data (do not disable) (1024 - 65535)'

syncthing on my desktop reports these errors:
tcp://x.xx.xxx.xx:22846
No connection could be made because the target machine actively refused it
tcp://default:22846
no such host (11:15:21)

syncthing on cloudron reports this error:
tcp://xxx.xxx.xxx.xxx:22846
no route to host (11:18:17)

Any help figuring this out will be much appreciated. Thanks.

[lucidfox]

Changing the Sync Protocol Listen Addresses in the Syncthing settings 'Connections' tab to 'default' seems to have done the trick.

[nebulon]

Thanks for sharing that information. Just to confirm, does that change also survive app restarts?

[lucidfox]

@nebulon No, the port gets reset to the one defined on the Cloudron dashboard when restarting the app (and there is only 1 listener listed on Syncthing). But the connection to the syncthing instances on my other devices work fine after that, even though they didn't initially on that port.

[nebulon]

Actually it has nothing to do with 2 instances on one server. Essentially it looks like the initial handshake between server and device does not work when the app is not on the default port. Once the handshake is performed it works regardless of port changes. This might just be a syncthing bug. Not sure yet.

[lucidfox]

That does seem to make sense. I just wanted to mention the second instance, as the default port wasn't an option.

[james]

@lucidfox I know it has been some time, but did you ever resolve this issue?

[lucidfox]

@james I've had multiple syncthings running on a cloudron server for a few years now without issues. Not sure if this is because the issue was resolved upstream, or if changing the default port for the initial handshake between devices has done the trick.