"Relay WAN" on local network with containerized app

Hi I’m using Syncthing between a NAS Asustor where Syncthing is installed in a Docker container, and 2 smartphones. I used filtering option on smartphone side to be sure to sync only when my home wifi is connected ( this works well once you give “always” permissions about localisation to Syncthing on android 13/14 ). Problem is that connection type is always “Relay WAN”.

My first idea about that problem is that Syncthing on NAS is in a container, that container is created with bridged address, so the local network that containerized Syncthing is not the same that my home network.

Is this a good lead and should I keep digging, for example trying to find a way to assign a “real” IP address to my container, or am I just messing up?

Containers are effectively behind a nat. You’d need to run syncthing outside of the container or with host networking in hopes for the devices to be able to discover each other on the network. You might also have firewalls on the nas etc, ap isolation on the wifi connection, disabled multicast networking in the router that might further prevent direct connection.


thanks for your answer .

Advising me to install syncthing outside a container doesn’t make sense, since syncthing is integrated into all NAS brands as a ready-to-use container. Example for asustor: https://www.asustor.com/en/app_central/app_detail?id=1091&type=

Couldn’t we define a way of making 2 nodes that aren’t necessarily on the same local network understand to try to do without the relay? I’m thinking of two nodes on either side of a router with NAT. Can’t the relay act as a “matchmaker”, telling the two nodes “hey guys, try to contact each other directly and do without me”? eg : giving a same “networkID” in node parameter.

Of course, if this kind of behavior is enabled, it’s up to the user to understand why it’s 2 nodes aren’t synchronizing, for example if the routing tables aren’t set up correctly.

You’re basically describing the role of our global discovery server. But this only works if any of the involved parties knows its own LAN IPs.

Oh the joys of thirdparty packaging…

I can only see two possible solutions if you want to stick with docker:

  • switch your container to host networking mode
  • use the LAN IP as an explicit listen address. These are exchanged via global discovery. This obviously only works if you’re using fixed IPs or define a static DHCP entry

Or just don’t rely on global discovery and manually set the remote device’s address of the NAS-Syncthing instance on the two smartphones to tcp://the.nas.ip.address:22000.

Also, I think it’s worth mentioning here, connecting to docker containers really isn’t all too tricky as long as local discovery works properly on the other side. But Android and local discovery isn’t the best match on earth. From any other kind of device I’ve never faced issues as long as the port mapping was done correctly, without setting anything custom/special.

The problem is more serious than that: The connection between the smartphones and my NAS works in a very hazardous way.

And when it works well (in QUIC WAN mode), it’s because I activate Nordvpn on the smartphone.

As soon as I disable the VPN, my smartphone disconnect from NAS, that is ends up on a different local network than the NAS, BUT… with the same WAN IP!.. Well, I strongly suspect that’s where it’s coming from, because of that: network status of smartphone on NAS side: ( always updating and rolling out ):

Address dynamic
<small>no recent network activity (16:21:39)
</small> quic://MYWANIP:22000
<small>no recent network activity (16:21:39)
</small> quic://
<small>no recent network activity (16:21:39)
</small> tcp://
<small>i/o timeout (16:22:04)
</small> tcp://
<small>i/o timeout (16:22:04)
</small> tcp://MYWANIP:22000
<small>i/o timeout (16:21:34)
</small> tcp://MYWANIP:55050
<small>i/o timeout (16:21:09)
</small> tcp://MYWANIP:55664
<small>i/o timeout (16:21:34)
</small> tcp://
<small>i/o timeout (16:22:04)
</small> tcp://
<small>i/o timeout (16:22:04)
</small> tcp://
<small>connected to self (16:21:24)
</small> quic://
<small>connected to self (16:21:54)</small>

and on smartphone side:

Adresse dynamic
<small>no recent network activity (16:27:18)
<small>no recent network activity (16:27:23)
<small>i/o timeout (16:26:58)
<small>i/o timeout (16:27:08</small>

we can see that both devices are trying to act something has if connected to same WAN… thats may explain why they cannot connect to eachother ( well… I suppose ).

at same time on smartphone side, log is complaining about not achieving sync…

Now, It would be nice to get a solution which use my local network when my smartphones are connected to wifi ( without VPN or with split tunneling ), but still be able to connect in WAN mode if not at home.

I have a rather complicated network:

  • 1st router (ISP’s one ) : MYWANIP <=(NAT)=> 192.168.2.x . No wifi
  • 2nd router : <=(NAT)==> 192.168.3.x…WIFI ( that is : smartphones are connected there ).
  • NAS is linked to both networks ( 2 network interfaces ) : and
  • Syncthing is in container on NAS. container has currently 2 network connections : and

Any idea about how an where I’m supposed to change settings ?

Yeah, using Global Discovery while being behind the same NAT-gateway while not being able to connect directly for some reason is not going to be very neat.

On the smart phones set the address of the NAS-Syncthing host to tcp:// dynamic via the regular App screen (I think, idk, I remember struggling with the syntax on the Android app at some point) or tcp://, dynamic if you use the web GUI (and ofc make sure all the relevant ports are mapped correctly).

While connected to the same LAN (or at least somewhere where it’s directly reachable via that address) as your NAS your smartphones will try to connect directly, via some external network they’ll use the regular global discovery methods.

Works like a charm here.


work like a charm here too . A big thanks for your help, specially the weird syntax between app and web for same parameter.

I finally put tcp://, tcp://,dynamic just because,normally, the wifi on my ISP’s router is deactivated, but can be used as a backup for my router.

I assume that syncthing tries specified connections in the order you input them, moving on to the next one if it fails…

I have found that, on my phone, setting a manual address for my nas works far better than relying on global relays to find the ip.

This is because my nas is in a different lan segment and behind a nat from my wifi, so basically the same as the OP. I also use dynamic for connection when travelling.


you mean that you already applied the same solution?

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