How abotu third one – keeping port constant?
Actually windows nodes or retched docker?
My nodes are running as windows service and ports are never changed in forwarding. So I am out of ideas now…
BTW: storjnet.info showing QUIC working while at the same time the node showing QUIC Misconfigured. 
Is it possible that the storagenode software dosen’t diagnose it correctly? Aka showing missconfig even when it’s working?
Both can be true. Storagenode checks connectivity once per hour. It also could be working for half the requests, and therefore show up outside as working, because it did work at least once.
Whatever the reason might be, it is a windows only issue to me. 50+ linux nodes having no quic problems while for the whindows nodes quic instability was introduced with one of the latest updates. Could this be related to a library update?
It’s not a storagenode software, it shows the status based on a satellite’s response.
This is interesting, because usually on Windows you do not need to do anything, except allowing the UDP port alongside with the TCP port in the firewall and forwarding both on the router.
And usually QUIC is misconfigured on Linux or FreeBSD nodes.
However, I believe that @arrogantrabbit is right, it’s likely related to having several network interfaces, which might have access to the internet. Like using a VPN or having several routable interfaces.
Ha! Increasing both read and write buffers to 7.5 MB solved it for the old Syno too.
Synology DS216+ with Celeron N3050 and 8GB RAM - QUIC OK.
I don’t know why it showed missconfig when I first checked upon restart.
Maybe the update to 131.7 helped too. 
No need to specify the internal address.
Right, as long as you have only one interface visible to the process (which is likely the case if you run it in the container) specifying that only interface wont’ change anything – it will route through it correctly, because there is nothing else to route through.