On Windows Phone 8.1, I'm getting "We're having trouble displaying this page... Refresh the page or try again later". E.g. for

Working websites:

I know bbc.co.uk can work because a) duh b) the BBC site worked at my home and I've used it many times (via thephone.coop, who resell service by TalkTalk).

It doesn't work at this other house though. The connection is by BT fibre (FTTC) with a BT Home Hub. It has IPv6 (though http://test-ipv6.com says the DNS can't reach IPv6-only DNS servers). It has BT's DNS typo correction hijacking enabled. I assume the DNS hijack is a default that could be disabled (but it's not really mine to mess with).

It doesn't look like a IPv6 issue. The BBC do not use IPv6 - ping6 bbc.co.uk returns unknown host (from a computer on the same net that can acces bbc.co.uk).

I don't think the BBC use HTTPS, so it's not that. I know they're planning to, but the computer that can access bbc.co.uk is not redirected to a HTTPS version.

http://6-dot-gfblip.appspot.com shows no problem with losses (or bad latency) on the wifi and DNS.

  • 1
    Does this problem also occurs on other browsers such as Surfy? Or is it occuring only on IE?
    – Kolappan N
    Aug 14, 2016 at 16:23

1 Answer 1


Looks like a certain pattern emerges in testing! Always remember to include the scheme in your URLs :).

HTTPS://bbc.co.uk works, as predicted by the pattern.

The pattern is broken by http://6-dot-gfblip.appspot.com and the original http://gfblip.appspot.com. That said, the long-distance probes to http://apenwarr.com (and eqldata.com, URL scheme unknown) suffer high latency (1000ms+) and very high loss (or latency greater than the 2000ms timeout). I notice http://gfblip.appspot.com is on ipv6 - am I seeing another pattern? Oh yes.

http://v6.testmyipv6.com works (as does the ds. version, which stands for dual-stack). http://v4.testmyipv6.com does not work.

I don't think there's a traditional HTTP proxy. It wouldn't be needed for performance on a "fibre" connection. I've checked some online tests looking at HTTP headers and caching behaviour, and a TCP traceroute. (Interesting note: http://www.proxydetect.com/ is broken, at least when accessed over ipv6. It reports a proxy using an ipv4 address (which would be even more pointless), but the ipv4 address belongs to Cloudflare, who do not provide ISPs with HTTP middlebox services).


The problem is with HTTP over IPv4, on this specific internet connection.

(And the phone OS, obviously. I've seen phones based on Android OS working here).

It's still not clear why. Nor do I have a workaround I could apply to the phone. There may be aircap in my future...

  • If you have a solution to your said question why don't you mark it as an answer?
    – Kolappan N
    Aug 14, 2016 at 16:24
  • You have to wait two days before the system lets you do that, I assume to give other people a chance to beat your answer :). If anyone else knew something qualifying as an answer for this, it probably would have better details than mine.
    – sourcejedi
    Aug 14, 2016 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.