FWIW not sure if this is applicable to you but if someone behind your public IP address happen to be using a program to download videos from them such as yt-dlp without enabling rate limits in the application then they will eventually start responding to your requests with TCP reset packets. I have a theory that a factor in their decision is the PTR reverse DNS record based on my testing. My work around was to do the automated downloading from random throw-away VM's in the cloud in a GNU screen session with rate limits and delays, then rsync what I want to keep when it finishes. Otherwise it could be just a network glitch.
Thanks for you suggestion and it is good to know this, but in my case I can rule out the cause.
There is a spike in downdetector for YouTube at the time of my comment, so it must have been a larger glitch somewhere...
Comments
FWIW not sure if this is applicable to you but if someone behind your public IP address happen to be using a program to download videos from them such as yt-dlp without enabling rate limits in the application then they will eventually start responding to your requests with TCP reset packets. I have a theory that a factor in their decision is the PTR reverse DNS record based on my testing. My work around was to do the automated downloading from random throw-away VM's in the cloud in a GNU screen session with rate limits and delays, then rsync what I want to keep when it finishes. Otherwise it could be just a network glitch.
Thanks for you suggestion and it is good to know this, but in my case I can rule out the cause. There is a spike in downdetector for YouTube at the time of my comment, so it must have been a larger glitch somewhere...