Sounds like a MTU issue. The "MTU" also means "Maximum Transmission Unit". This has to do with the largest packet that you can send on a particular link. In the old days, routers would break a large packet into fragments when they were about to transmit a packet onto a link with a lower MTU.
But this slows down the router and your connection. So these days, windows sets the "Don't Fragment" flag - and rather than break the packet, the router will respond with an ICMP packet that tells your system to send smaller packets - and your system will send smaller packets and avoid the fragmentation load and slowdown.
Problem is that sometimes the ICMp responses do not get through. Security professionals used to block all ICMP, willy-nilly. ICMP (except perhaps Ping) should never be blocked.
http://www.netheaven.com/pmtu.html is a great discussion of this
What happens is,
1. You open a connection to site X. You tell them that the largest packet you will take is 1500 because that is the MTU on your wireless net.
2. The packets that are used to open the connection are small packets. Then, when the data starts flowing, large packets are sent. One of the packets is too big. The router between them and you sends the "whoops, too big" packet, and they filter it at their end.
3. They resend the packet and it never gets through. You eventually give up.
The problem is on their end - but let me ask this:
If you connect to the modem via a wire, does it change anything? I honestly don't think it is your problem, but it could be - if this is not the issue.
To diagnose, use this scheme to set your MTU to 576.
and then see if you can access these sites. If you can access these sites now, then this is your problem.
I do not know anything about your topology, but if you happen to have a link to you with a reduced MTU (are you running PPPoE? Who is your supplier?) and you can figure out what that MTU is, then by setting the MTU on the wireless link to that number, you will avoid having these sites send you large packets. The ICMP response never gets there but it is never needed.
What I don't get is why a reload would EVER work. The response should either go through or not. Resending the same stream should cause a problem in the same place.
Here is an alternate theory:
Years ago, I had a problem downloading a particular file via DSL. Just one file...out of many hundreds I'd downloaded. And occasionally I had a problem with a bit of web content but who cares? But this was a file and it was a hard failure so I could look at it further.
I had my friend compress the file (which changes the pattern of data in the file), and got a copy of the compressed file. Then I blew up the file and looked in the file with a hex editor and, paid special attention to the hunk that was just past the part where the file had hung.
Well, the ping command on Linux allowed you to send a ping with not only a particular buffer length but a particular payload, and what I discovered was that when I sent a particular packet (that matched the part of the file that failed) I would never get the response.
I called my ISP and explained that I had a ping that would fail when certain data came through but not when other data came through and that I could ping with a packet of a certain length but when I sent a packet with different data and the same length I never got a response.
The only difference was the data part of the packet.
I ended up at the highest tech level and they started tracing things while I ran my ping - and suddenly my link went completely dark for a minute and then started working. They had replaced my link card - on my ADSL link. It was sensitive to the content of the data. The internal indication they got was that the checksum had failed so the packet was dropped, but the hardware was broken and they were miscalculating the checksum, the packet was actually fine when they looked at the dump. (As I recall, 64 bytes of hex 0f0f0f0f0f0f would fail so it was simple to see that what I sent got there, by inspection).
Now, there is a possibility that the link, either the wi-fi at your end or the DSL link hardware is broken and is broken in a way (like mine was) where it is data sensitive. And some data causes it to be likely to toss the packet on the floor, while other data makes it through just fine.
If I was a techie, I would get a copy of a program called Wireshark. This program used to be called ethereal, and it allows you to trace what goes over your IP connection and through your adapter. If you understand IP you might be able to see where the TCP connection stalls and then when you restart it and it goes through, what is in the packet following the stall. If it fails in the same way every time, it might be possible to use something like wget for windows (which see: like http://gnuwin32.sourceforge.net/packages/wget.htm )
and to get a particular file and cause a reliable failure, or a high percentage of failures, and with that in hand to call your ISP.
If you can cause the problem to happen with multiple computers at your end you might be able to get them not to look at your computer.
A trace of a failing wget would be the next thing I would look for. Hope this helps, let us know what happens.
A final theory is that, to stop people from filesharing, the ISP is rolling your IP address every few minutes. By breaking a PPPoE connection and forcing the router to reconnect and always supplying a new IP address, or doing the same sort of thing with a short DHCP timeout and rolling the IP address, they could do a lot to interfere with the popular programs that share large files, like bittorrent and such.
You could diagnose this by connecting to your router and determining what your exterior IP address is, then, when you get a hang, see if the exterior IP address has changed.