I would suggest using lftp. You will get better diagnostic messages. However, lftp itself must be downloaded first, e.g. as a part of cygwin or from the above mentioned link (not an exe file!). That archive must be unpacked into some directory where lftp can be executed. Cygwin version includes lftpget:
lftpget -c http://example.com/JavaSetup7u21.exe
Bare-bones lftp command is a bit less obvious:
lftp.exe --help
lftp.exe -c get http://example.com/JavaSetup7u21.exe
To answer your non-question
The Opera browser was playing similar tricks on me as in your case, aborting downloads. That was probably due to poorly configured or poorly working router that dropped packets. Lftp has superior reconnection abilities and would still download the files completely.
It is possible your ISP has a Transparent Proxy
You have ruled out the usual suspects for this sort of issue, which leads me to believe that might have an ISP that uses a transparent proxy - I'll describe that below.
To be clear - I'm not 100% positive this is your issue - it seems plausible and is worth looking into - it's becoming more and more common a problem.
In order to explain this (without knowing your background), I need to provide some very basic background on encrypted communication protocols, so bear with me.
If you don't care about the background info, jump to the Summary section where I list some ways to test if a proxy is causing your issues.
Unencrypted TCP Transactions Work
We know that speedtest.net is working (reasonably) well. That test essentially builds its own unencrypted messages / payload and afterwards uses TCP connections between the remote and local hosts.
Encrypted TCP Transactions Do Not Work
On the other hand, both of the sites that you cite as being problematic are conducted over secure connections using https.
https and transparent proxies
https is used to create a secure (encrypted) communication channel over an insecure channel (e.g. the internet).
TLS/SSL - An application conducting an https transaction creates a TLS/SSL connection to the remote client which, among many other things, provides the client with the information necessary to decrypt the messages from the host.
client/host trust - This secure handshake is based on establishing a trusted relationship between host and client based on pre-existing 'trusts' which are granted by Certificate Authorities (aka ca certs).
MITM - Attempts to 'break into' a secure TLS/SSL channel are sometimes called a 'man in the middle' (mitm) attack, and are usually done by the attacking 3rd party host pretending to be the host to client, and the client to the host. In other words, the client thinks it's talking to the remote site it connected to, but it is actually talking to a third party proxy.
Transparent Proxy - One method to to do this is with what's called a transparent proxy. I can't start to explain how they work here - read this for a good explanation. For a transparent proxy to work, the client usually has to have actively accepted (trusted) a certificate from that proxy - e.g. software provided by the ISP, but there are ways around that.
https now insecure - The transparent proxy, which functionally is a man in the middle attack, allows the host running the proxy to fully decrypt all https traffic for whatever reason (corporations for policing their employees, ISPs for spying on their customers and to allow them to cache content that gets provided encrypted, criminals for stealing sensitive information, etc.). Your passwords, bank account info, sensitive emails - all fully accessible by whomever it is in charge of the proxy.
Summary
If your ISP has a transparent proxy, it could be interfering with your secure communications and not impacting your insecure ones, which is why I think this might be your problem. Even though normal https web browsing is not impacted by this in your case, there are significant differences in the nature of the traffic for downloads vs. web pages that could trigger the issue. In some cases (my own company for example), the proxy will intentionally behave this way - large downloads slow down to a trickle if the proxy 'decides' that a particular file needs inspection before allowing it through.
Tests
If any of these tests indicate you are behind a proxy there is no need to continue with the next tests; jump to the end. I got the proxy detection tests from here: Source
Go to this website http://whatismyip.network/proxy-check and see if it detects that you are behind a proxy. If it says you are not behind a proxy, write down what it says your public IP address is.
Go to http://whatismyip.network/ and check it's reported IP address against the one from step 1. If they don't match, you ARE behind a proxy.
Try this proxy detection site (different approach) http://www.lagado.com/proxy-test
Last proxy check (they can be very well hidden). This is the most effective check I'm aware of, but is more involved than the others. http://www.lagado.com/tools/cache-test
Try a variety of downloads from http sites and compare them against https sites. I put two links below for a 400M download, one http the other https.
VPN Test and Solution
The only way around an ISP's proxy is to use a VPN service. That will ensure that they aren't manipulating or consuming your data, and possibly degrading your service at the same time.
If you don't have a VPN service to test with, there are a bunch of free ones. I suggest cyberghost. Once you have setup and connected to the VPN, check your download speeds again (http vs https) - even if no proxy was found, it's possible that a VPN will fix whatever it is your ISP may be doing to your data.
If the VPN does fix your issue, I highly recommend moving on to a paid VPN service for long term use - you get what you pay for. private internet access is a good one to look at.
Best Answer
You could: