Relay, Discovery, and Sync client all-in-one

So I’m building a VPS with the relay and discovery servers both running on it locally. Now I want to install the syncthing client along side them. What I’m trying to do is find a way to secure the “client” by default. I don’t want a default shared folder at all. I can set the user/pass and TLS boolean no problem. Is the best way to go about this to setup the skeleton of a config.xml and start from there? Or should I use the REST API to do the configuration? Or is there some sort of manual config through the web GUI that HAS to be done?

I’m trying to make the end result reproducible since it’s an IaC type deployment with Terraform and Ansible.

Thanks in advance to anyone who helps

Have a look at the syncthing generate CLI sub-command. It’s intended for exactly this purpose, including --no-default-folder. Feel free to ask if any details are unclear, otherwise have fun at Syncthing — Syncthing documentation :wink:

After using that, I usually script the syncthing config CLI afterwards to enable TLS and such, add custom discovery servers, etc.

1 Like

Note that discovery announcements won’t make sense and will be unusable when connecting from the same machine, as the ip discovery will see it as loopback address.

I don’t need it to see itself but it should see the other clients on the same discovery server, correct?

Awesome. Thank you for this. I’ll give that a go.

Yes, but if A runs on the same machine as discovery server, addresses B get for A will make no sense, in which case you can only get B to connect to A.

So it’s going to see the loopback address even if the hosts file has the hostname and fqdn as the public IP?

That has no meaning, as that is “what address do I think I have”, and what we really want is “what address did this device connected from”, to account for NATs, firewalls etc.

So no, it will not work.

1 Like

So pragmatically speaking, don’t run a discovery server on something also functioning as a sync “client”? Is there any issue running relay/disco on the same server?

I can’t confirm this, at least on Linux. I also run a discovery server and a syncthing client on the same machine and the discovery server does see the correct IP.

If I have a machine with IP address, I can do local communication with either:

  •, which is independent of any other machine IP
  •, which the host also routes to itself, as long as it’s an IP address from one of its interfaces.

Since my DNS resolves to*, the discovery server sees the local client as connecting from, just as any external client would. There is no localhost address involved at any time. This also works with IPv6 as well.

(The packet-reflection via network interfaces may not be as optimized as going through loopback, but that doesn’t matter in this case)

*I use different FQDNs for IPv4-discovery and IPv6-discovery, both are different from the machine’s hostname, but resolve to one of its public IPs.

1 Like

I guess this all depends on routing rules, and I guess might end up being configurable somewhere in the kernel. I guess I would not be surprised if the routing for an ip that the kernel thinks it owns on its own adapter got short circuited to not go out to the actual network.

I am saying what I am saying because people complained before that this didn’t work, hence I am just echoing what they said before, but perhaps the setup involved docker or something like that that made things worse.

I guess you can try out and see.


I will be working on it late this week and will report back how it behaves. If I need to spin up another VPS it’s no big deal but I’ll post the configuration on here with the behavior I’m seeing from it when I’m done.


To prefix this, I’ve created a local strelaysrv user on this server and setup the disco/relay/sync client to run under this user.

useradd strelaysrv
mkdir -p /srv/{strelaysrv,stdiscosrv,syncthing}
chown strelaysrv /srv/{strelaysrv,stdiscosrv,syncthing}

I’m trying to restrict the administrative access to local only so I’m hoping I can still use this (/var/run/st.sock) GUI address for the local socket connection and REST API… can anyone confirm? I read the CLI client is obsolete elsewhere in the forum

sudo -u strelaysrv syncthing serve --gui-address=/var/run/st.sock --config=/srv/syncthing/config --data=/srv/syncthing/data --logfile=/srv/syncthing/log/syncthing.log --no-browser

Log output from launching with these parameters:

[monitor] 2022/12/15 13:20:31 INFO: Log output saved to file "/srv/syncthing/log/syncthing.log"
[start] 2022/12/15 13:20:31 INFO: syncthing v1.22.2 "Fermium Flea" (go1.19.2 linux-amd64) 2022-11-28 03:48:37 UTC
[Z3UHU] 2022/12/15 13:20:32 INFO: Single thread SHA256 performance is 1460 MB/s using minio/sha256-simd (390 MB/s using crypto/sha256).
[Z3UHU] 2022/12/15 13:20:32 INFO: Hashing performance is 930.30 MB/s
[Z3UHU] 2022/12/15 13:20:32 INFO: Overall send rate is unlimited, receive rate is unlimited
[Z3UHU] 2022/12/15 13:20:32 INFO: Using discovery mechanism: global discovery server https://localhost:8443/?id=Z3UHUUZ-X2SH2R5-WN5BBRW-KEWY3OV-PAU43LW-XNODJGK-FFYRJFF-IGR5CQU
[Z3UHU] 2022/12/15 13:20:32 INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027
[Z3UHU] 2022/12/15 13:20:32 INFO: Using discovery mechanism: IPv6 local multicast discovery on address [ff12::8384]:21027
[Z3UHU] 2022/12/15 13:20:32 INFO: TCP listener ([::]:22000) starting
[Z3UHU] 2022/12/15 13:20:32 INFO: Relay listener (dynamic+ starting
[Z3UHU] 2022/12/15 13:20:32 INFO: GUI and API listening on [::]:36943
[Z3UHU] 2022/12/15 13:20:32 INFO: Access the GUI via the following URL: https:///
[Z3UHU] 2022/12/15 13:20:32 INFO: My name is "cloudcore"
2022/12/15 13:20:32 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See for details.
[Z3UHU] 2022/12/15 13:20:32 INFO: QUIC listener ([::]:22000) starting
[Z3UHU] 2022/12/15 13:20:33 INFO: quic:// detected NAT type: Not behind a NAT
[Z3UHU] 2022/12/15 13:20:33 INFO: quic:// resolved external address quic://MY_ACTUAL_PUBLIC_IP_IS_HERE:22000 (via
[Z3UHU] 2022/12/15 13:20:42 INFO: Detected 0 NAT services

It looks like using quic/, it did resolve the correct public IP address… does anything look off to you guys?

Well I replied with what I’ve deployed and found but for some reason my reply was hidden?

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