Local Discovery Binding Problems

First time setting up Syncthing, so I’m not really familiar with everything yet. Having an issue with Discovery port binding I’m not sure how to understand.

I’ve got two (eventually more) Windows 10 systems each running two (eventually more) instances. Each instance is started as a different user on system startup. Each has its own GUI Listen port, and each has Sync Protocol Listen Addresses of the form tcp://, quic:// where the ports are different for each instance. NAT traversal, Global Discovery, and Relaying, are all turned off, but Local Discovery is on. The idea is that I want to connect only to specific hosts that I control, without relying on external services at all.

Here’s the thing I’m seeing that I’m not sure how to understand: on one of my hosts, under “This Device”, I typically see a red “0/2” listed in the “Discovery” line, where clicking on it gives me the following:

  • IPv4 local: listen udp4 :21027: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
  • IPv6 local: listen udp6 [ff12::8384]:21027: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

The other instance on the same host has no trouble and shows 2/2 for Discovery.

How do I interpret what I’m seeing here? How do I prevent port conflicts from multiple instances running side-by-side?

Making things weirder, occasionally, I can get a 2/2 on one instance and a 1/2 on the other (that is, conflict trying to grab the UDP port on the IPv4 address but on the IPv6 address working okay), but it is inconsistent. Sometimes it works, and sometimes it doesn’t.

When I see it working, looking at the Windows Resource Monitor shows the port (21027) in use alternately by two different processes. When it isn’t working, that port just seems to be held forever by just one of the processes.

Any ideas as to what I should be looking for or how to understand the issue here?


Local discovery over IPv4 can only ever be used by one process per computer, because it needs to open a listening port which is indeed exclusive to one process. Local discovery over IPv6 can work with multiple processes when the APIs allow multiple processes to open a multicast listening port. I don’t know if that’s the case in Windows with the APIs Go use or not.

In short: do not count on local discovery with more than one process per computer.

If you have multiple network adapters you might be able to do some hacks with having each process bind to discovery on only one of them. Not obvious if it’s worth the trouble or will work reliably.

Any idea why it would only not work sometimes (most of the time)? On some startups I see a 0/2 with errors. Other times I get 1/2 on the Discovery line.

Is it possible that whether two processes listening on the same port can happen is dependent on the timing of when they each ask for it?

By the way, I much appreciate the existence of this tool. This is a very simple, straightforward need that hardly any other pieces of software (especially cross-platform software) are meeting well.

1 Like

No idea why there are inconsistencies, sorry.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.