You can't see everything from your own connection, but you can see a lot.
Take some pcaps of downloads that don't work. See if there's some common thing going on. Are you getting packets slowly with minimal loss or are there many missing packets? Does it seem like a path MTU issue [1]? Is the RTT reasonable?
Traceroutes from your side aren't the most helpful, but see what's the same and different between download IPs that work well and those that don't. If we assume congestion is from the internet to you, traceroutes from the download servers that don't work would be most useful, but that's hard to get. Sometimes you can find a hosting provider with test download urls and a looking glass, which can be pretty helpful if that's what you're experiencing.
Definitely look at ipv4 and ipv6. It's pretty common to get different routing between the same two endpoints on v4 and v6, so you get more debugging.
If it is a routing problem, be sure you're testing same IPs for download between native and VPN, if you download by hostname and the DNS resolves differently, try both IPs both ways... maybe you're just getting poor selection from DNS which can be addressed in different wayss. If your native DNS always gives you cross country servers and your VPN is local and gets local servers, there you go.
But if you do figure out the problem, you also need to find a way to escalate. Chances are phone support isn't going to be super helpful. Explore reddit to see if people get results there, find out what the replacement for dslreports is, etc.
Edit to add: when you do reach out, you want to share a concise summary and easy to repeat test; not so much all the research you did behind it. But ... that test should include multiple sources for the download or support will say it's a single site issue and close the ticket.
[1] I always blame PMTU, what does my test here show http://pmtud.enslaves.us/ If you don't get OK in all the boxes, that could be part of the problem... But that's usually slow start, not slow throughput after starting.
Take some pcaps of downloads that don't work. See if there's some common thing going on. Are you getting packets slowly with minimal loss or are there many missing packets? Does it seem like a path MTU issue [1]? Is the RTT reasonable?
Traceroutes from your side aren't the most helpful, but see what's the same and different between download IPs that work well and those that don't. If we assume congestion is from the internet to you, traceroutes from the download servers that don't work would be most useful, but that's hard to get. Sometimes you can find a hosting provider with test download urls and a looking glass, which can be pretty helpful if that's what you're experiencing.
Definitely look at ipv4 and ipv6. It's pretty common to get different routing between the same two endpoints on v4 and v6, so you get more debugging.
If it is a routing problem, be sure you're testing same IPs for download between native and VPN, if you download by hostname and the DNS resolves differently, try both IPs both ways... maybe you're just getting poor selection from DNS which can be addressed in different wayss. If your native DNS always gives you cross country servers and your VPN is local and gets local servers, there you go.
But if you do figure out the problem, you also need to find a way to escalate. Chances are phone support isn't going to be super helpful. Explore reddit to see if people get results there, find out what the replacement for dslreports is, etc.
Edit to add: when you do reach out, you want to share a concise summary and easy to repeat test; not so much all the research you did behind it. But ... that test should include multiple sources for the download or support will say it's a single site issue and close the ticket.
[1] I always blame PMTU, what does my test here show http://pmtud.enslaves.us/ If you don't get OK in all the boxes, that could be part of the problem... But that's usually slow start, not slow throughput after starting.