Syncthing kills my network connection on one PC only

I have Syncthing running on two Windows 10 machines. Right now they aren’t set up to autostart or anything. I’m also running it on an Android phone.

The sync between the Android phone and one PC work perfectly.

The sync between one PC and the other works for about a minute, then one of the Windows machines loses its connection to the network, internet, etc. The other machine is not affected at all.

I’ve tried turning off the NAT option in Syncthing, and specifically port mapped both machines to a separate port, but the same process occurs. I start Syncthing. The two computers connect and begin syncing. Then the one problem machine loses its network connection and the message in the log reports the following:

wsarecv: An existing connection was forcibly closed by the remote host.

Sometimes the network connection will be restored on its own, but the issue just repeats.

If a regular application is able to kill your network interface, it’s your interface you should be concerned about.


I couldn’t disagree with you more. There are any number of situations in which a “regular” application could cause network card issues if not configured properly, which is likely the case. My network interface is fine - that is to say this problem has never occurred with any other application I’ve used in the 2 years I’ve had this particular computer. Perhaps I did not explain my problem clearly enough because I don’t completely understand what might be wrong, which is why I came here for assistance. But the issue is not my network connection. The issue is with Syncthing.

For anyone who has a moment to spare and is willing to help me troubleshoot: To add additional details, as long as the folder is set to pause, my network connection is fine. If I unpause the sync, it will sync to my other networked computer for a minute, successfully copying files, then disconnects. My computer will remain connected to the router but is unable to see other computers on the network and can’t access the internet.

I’m wondering where the conflict is. I have tried giving each computer the direct IP address of its counterpart the network, but the same issue occurs.

How does it look if you pause Syncthing after the “network outage” occured? Can you unpause and it works again immediately? Can you go browsing?

1 Like

Thanks so much for the response. If I pause the folder, the connection to the network will be functional again within 10 seconds and sometimes instantly.

Your network connection completely dies. The chance that it’s not related to your Wifi/LAN adapter or your router is next to zero.

Which hardware is involved?

1 Like

Yeah, I would personally check the router first. If possible, testing with a different router would help very much.

1 Like

Desktop 1.0 Gbps LAN connected to Nighhawk R7000 set in AP mode (wifi turned off) with stable 702 Mbps 5G connection to router. (This desktop is the only device connected to the R7000 and it easily streams VR games to the main router then to an Oculus Quest 2 with no discernible lag).

Main router: Asus RT-AX88U (tried turning off QoS with the same results). Never had a single issue with this router or any of the several dozen devices that connect to it. No issues with copying files over the network via Windows File Explorer.

Based on some suggestions I found on another thread, I turned on LAN limits and set my limits to 20/30/40 MiB/s as a test while running a continuous ping to Google. This seemed to bring a little more stability to the connection, with pings dropping almost immediately if I go up to 40 MiB/s. It seems like the speed is capping out on its own around 34 so I reduced to 30 to see if the connection would remain stable. It lasted longer but eventually the pings died. Tried again with 20, which is well under the max speed Syncthing was getting on its own and much lower than a direct file copy through File Explorer. Again, the connection lasts longer, the lower I set the limit, but eventually the pings start timing out.

1 Like

Could this be a bufferbloat problem? Test: Bufferbloat Test by Waveform

Desktop <— LAN —> R7000 <— Wifi (client mode) —> RT-AX88U


As other devices seem not to be affected, i’d rule out your router. My guess would be on the R7000. If that’s the case you should be able to replicate the crash with any other device hooked up to to it.

1 Like

Yes, that’s correct. Desktop > LAN > R7000 > Wifi (Bridge Mode) > RT-AX88U

I updated R7000 to latest version, LAN card to latest drivers, and made a few small tweaks. I was able to get 50-60 MB/s for 8 minutes solid before the pings dropped out again and the sync dropped to 0. It’s baffling me why it runs fine for a few minutes then just suddenly stops. As soon as I close Syncthing the pings start back up again.

As a test, I disabled my LAN adapter and re-enabled the Wifi card in my desktop. It doesn’t get as strong of a connection so it’s only around 300mbps link. This lowers the transfer rate of the sync considerably, but I keep my connection, at least from my limited testing. I just don’t know if the problem with the R7000 route is the result of connecting through the bridge (which has never had issues with any other network connection/download/sync/software of any kind) or because of the higher transmission rate.

Does the R7000 show display any error in its logs?

I have it set to include everything possible in the logs but nothing shows up related to the connection dropping. It’s mostly some time sync data and admin logins.

Try to disable all features and security functions. Ultimatly you could try a factory reset.

I’m not sure I follow. What security function would be kicking in only after 5-10 minutes of Syncthing running? I’ve done about 5+ more tries with various changes here and there including adjusting some port mapping, rolling back my LAN adapter to an older driver, etc, and the problem is very consistent now, made especially clear thanks to a continuous ping running.

The sync works just fine for roughly 5-10 minutes, with transfer rates fluctuating between 40-60 MB/s. Then suddenly the pings will time out, the sync drops to 0, and the network connection is dead. As soon as I close Syncthing it pops back up (within 10 seconds) and the pings resume.

Is there anything else on the R7000 side that can be tested while the dead computer is not working; I’m thinking that the radio in the R7000 or AX88U may be overheating and the link between the two is degrading. This could be causing tons of packet loss such that the connection fails due to the excessively large queues filling up. The other thing to try would be rate limiting synchthing to say ~300 MiB/s in both directions to imitate the wi-fi connection that seems to work.

I plugged in a laptop to the R7000 and recreated the ping drop scenario. The laptop maintained a connection to the network and performed successful speed tests and file copies while the desktop continued to show a string of timed out pings, so that completely rules out any damaged routers or overheating scenarios.

Also found this interesting detail. When the pings start to drop, if I pause the sync I will eventually get back some connectivity, but at a much slower rate. Once I close syncthing I get back MOST of my speed again, but the ping is about double what it would normally be. I actually have to disable the network card then re-enable it to get the pings back to the lowest ms. It’s very odd. By the way, the ping ms stays low during sync, it only shoots up once they start dropping and I disable the sync.

Maybe you could check swapping the network card driver to the manufacturer one instead of the windows (update) default. That helped me one time a while ago. Also some drivers provide a property sheet in the device manager where roaming aggressiveness , preamble, power saving and so on can be configured. As a last resort you could try this. For one of my devices the cause of being better after disabling the card and then re enabling was 2.4/5ghz dual band roaming where the signal was good in 5ghz and after a while under pressure the driver went to 2.4ghz where my tplink openwrt router is well-known by the community to have problems with an overheating wifi module ending up in crashes of the driver and low throughput with high pings.

So its pretty much down to a missbehaving network interface or funky security software.

1 Like

Thanks for the suggestions. It’s an ethernet card connected to an R7000 router in bridge mode so there is no roaming aggressiveness, etc to deal with. I also tried installing the manufacture drivers, with no difference in results.

The connection to the R7000 and from the R7000 to the main router has been rock solid. As I mentioned before, I routinely run VR games on my desktop, streaming from the computer through the network card to the R7000, from the R7000 to the main router, and from that router to my Oculus over 5G with zero frame drops and around 10ms lag (indiscernible) for hours at a time. I’m positive there are no issues with my hardware or network settings, as the only issue I’ve had even remotely like this has been with Syncthing.

I don’t have any AV software installed (aside from Windows Defender), and the first time I ran Syncthing I received an automatic Windows Firewall pop-up, which I allowed. I also double-checked Windows Firewall settings, and even disabled it completely for one of my tests. This rules out anything security related, although that was never really a question to begin with since a security setting wouldn’t suddenly block all traffic after 10 minutes of allowing it.

At this point, I’ve tested so many times that the sync has completed with a 1.2 TB sync. I’ve subsequently make smaller changes to the files on either side and the sync works. But I haven’t added any large files, so I imagine once I do I’ll end up with the same issue again. In the long run, I might end up having to go back to Resilio, although I prefer the interface and features of Syncthing. I just wish community troubleshooting didn’t automatically assume there is nothing wrong with Syncthing and that the problem must absolutely be with something else. A view I don’t share.