From what I've read in the thread above the issue seems to be to do with the way that they're filtering traffic as it passes through their infrastructure - packet inspection which is being acted upon to control what sites are visited and those actions end up interrupting IP communication and stalling some packets from working as they should. Hence why using a VPN of whatever colour is the one thing that seems to 'fix' the problem since the content of the packets can't be interrogated and traffic can't be interrupted or 'mangled' in a way that stops the communication.
Although 'fix' isn't really the right word because of course VPN usage often leads to other problems with sites that use security measures to detect suspicious activity (like the use of different IP addresses as a VPN would imply) and can lead to bans or blocks on services. I wouldn't even want to think what would happen if I tried using my banking apps via VPN, seems a sure fire way to give yourself a headache!
I bet there's some rule(s) somewhere in the big mess of content filtering system that they have that's screwing things up but working out where it is or why it's happening is too much. Think hundreds of lines of firewall code that someone wrote with great inspiration 'back in the day' but that someone has now moved on and the new guys won't go near it... One day the erroneous line(s) will accidentally get removed and things will be fine again. One day. 😛
EDIT: reading that back - though why it seems to happen so haphazardly I don't know... maybe there's one node in a cluster of filtering nodes that is configured badly and only throws up the problems when it gets used in a round robin kind of way? Who knows. Not Three apparently. 😄
PS
I don't know if anyone is still keeping track of pages that have issues but the reason I came back to this thread just now was when checking on premium bonds at National Savings and Investments I got the usual PR_END_OF_FILE_ERROR:
https://secure.nsandi.com/thc/policyenforcer/pages/loginB2C.jsf
