Very strange network issue - specific sites not loading

First off, I apologize if I posted to the wrong exchange, I really wasn't sure where this question fits.

For quite some time I've been having this very strange problem with my home internet connection that is definitely either my router's or my ISP's fault, but my ISP is being pretty helpless at debugging it.

For the most part my connection works great--no downtime and I consistently get pretty much 100% of the speed I'm paying for.

However there is one specific problem: some websites have this very strange behaviour where they will take a very long time to load. Examples of such websites are en.wikipedia.org, www.canadapost.ca, and www.theweathernetwork.com. With these websites, whenever I try to load a page, at first, nothing will load at all, and the status bar in Chrome will read "Establishing secure connection.." for a very long time, and eventually it will give me a "This site can't be reached" error. If I reload and try again, after a few times, eventually the site will load, and once that website is loaded, I can browse around that website freely without issues for about 15 minutes or so, then the problem will return.

It's not a problem with my firewall or PC settings. I've already tried numerous things to weed out what the problem is and I've determined it has to be either my modem-router, or my internet connetion itself, becuase it happens to all devices connected to my network (desktop, laptop, smartphone, etc.) and with my smartphone, when I switch to mobile data the problem goes away.

I've filed a support ticket with my ISP and they've walked me through all the obvious steps (factory reset of the modem, etc.) and now they're not being that helpful.

One thing I've done to try to test is I've run curl commands for the websites that have this problem and I've noticed something; with all the websites having this problem, "curl -v [url]" returns an HTTP 301 instead of a 200.

Anyone have any idea what the hell is causing this so I can point my ISP's technicians in the right direction?

EDIT: It was pointed out that I wasn't including https in the curl commands, that caused the 301 returning. But now that I am including https I've noticed something interesting:

When running curl -v against an https site that is not part of the problem (such as facebook), I end up with normal output.. but for a website that is, it looks like this:

$ curl -v https://www.canadapost.ca
* STATE: INIT => CONNECT handle 0x600057810; line 1413 (connection #-5000)
* Rebuilt URL to: https://www.canadapost.ca/
* Added connection 0. The cache now contains 1 members
*   Trying 2600:140a:0:18a::1dc5...
* TCP_NODELAY set
* STATE: CONNECT => WAITCONNECT handle 0x600057810; line 1466 (connection #0)
*   Trying 23.34.200.189...
* TCP_NODELAY set
* Connected to www.canadapost.ca (2600:140a:0:18a::1dc5) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057810; line 1583 (connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600057810; line 1597 (connection #0)

It then hangs there, for a really long time, and then eventually it continues and ends with:

* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CA; ST=Ontario; L=OTTAWA; O=Canada Post Corporation; OU=Akamai SAN SSL OV; CN=www.canadapost.ca
*  start date: Jan 13 00:00:00 2017 GMT
*  expire date: Jan 13 23:59:59 2018 GMT
*  subjectAltName: host "www.canadapost.ca" matched cert's "www.canadapost.ca"
*  issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SSL CA - G3
*  SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x600057810; line 1618 (connection #0)
> GET / HTTP/1.1
> Host: www.canadapost.ca
> User-Agent: curl/7.54.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x600057810; line 1680 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x600057810; line 1807 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x600057810; line 1817 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 301 Moved Permanently
* Server AkamaiGHost is not blacklisted
< Server: AkamaiGHost
< Content-Length: 0
< Location: https://www.canadapost.ca/web/en/home.page
< Date: Mon, 22 May 2017 22:01:55 GMT
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000
<
* STATE: PERFORM => DONE handle 0x600057810; line 1991 (connection #0)
* multi_done
* Connection #0 to host www.canadapost.ca left intact
* Expire cleared

Solution 1:

It ended up being caused by IPv6. I disabled it on my router and set it to IPv4 only and the problem is now gone.

Solution 2:

All three of these sites appear to be HTTPS only, If you are starting which http:// addresses, these sites are informing your browser that they have move permanently to https with the 301 messages. This will be part of the 301 message. You may get additional redirects that add a path for the default page. The 301 redirects are likely a red herring.

Long delays like this are common if you have DNS conmectivity issues. However, I would expect that to occur on the first attempt.

All these sites are IPv6 capable. If it appears you have IPv6 capability, chrome will likely attempt to use IPv6 rather than iPv4 to connect. Negotiating HTTPS can involve several connections to different servers. If any of these are blocked or down it can cause delays.

It may help to use the Chome Developer Tools (CtrlShifti. Select the Network tab which will show you load times for page components. Hover over the first slow connection for details on timings.