04 May 2026

How GitHub Pages' old IPs broke HTTPS behind Cloudflare

Google Search Console reported for a while Redirect error on a handful of my pages. The site worked fine in a browser, every page loaded over HTTPS. However, some weeks ago the time came to deal with this error. On top, I also had to make sure the existing Cloudflare integration kept working.

This is my guide for how I managed to fix it. The cause turned out to be two DNS records that had been quietly wrong for years.

The symptom

Any URL without a trailing slash went through this chain of redirects:

https://example.com/tags/Azure     (no trailing slash)
  301 -> http://example.com/tags/Azure/     <- downgraded to http
  301 -> https://example.com/tags/Azure/
  200

Three hops, and the middle one drops out of HTTPS. Google treats that as a redirect error and will not index the URL.

Finding out who generates the redirect

The response headers tell you which layer answered:

curl -sSI "https://example.com/tags/Azure"

HTTP/1.1 301 Moved Permanently
Server: cloudflare
location: http://example.com/tags/Azure/
cf-cache-status: DYNAMIC
x-github-request-id: 36E3:5BD8F:10B634F:1416803:6A6EE4B2

x-github-request-id means the redirect came from GitHub Pages and merely passed through Cloudflare. cf-cache-status: DYNAMIC rules out a stale cached response. So GitHub was writing http:// and the CDN was innocent.

Curl against a specific GitHub Page IP directly

This is the step that solved it. curl --resolve sends the request straight to a chosen IP while keeping the hostname and SNI intact, which bypasses the CDN entirely:

curl -skI --resolve example.com:443:185.199.108.153 \
  "https://example.com/tags/Azure"

Run it against each candidate origin IP (GitHub’s current official Pages IPs) and compare:

199.108.153    location: https://example.com/tags/Azure/
199.109.153    location: https://example.com/tags/Azure/
199.110.153    location: https://example.com/tags/Azure/
199.111.153    location: https://example.com/tags/Azure/
30.252.153     location: http://example.com/tags/Azure/
30.252.154     location: http://example.com/tags/Azure/

The current GitHub Pages addresses honour the scheme of the incoming connection. The two older ones return http:// no matter how you reach them, including over HTTPS.

My DNS in Cloudflare pointed at those two old addresses.

The fix

192.30.252.153 and 192.30.252.154 are GitHub Pages IPs that were deprecated years ago. They still route, still serve the site, and still return 200 — which is exactly why nothing looked broken.

The current and correct IPs to enter in your Cloudflare DNS are:

199.108.153
199.109.153
199.110.153
199.111.153

Replacing the apex A records fixed every affected URL immediately, down to a single hop:

https://example.com/tags/Azure
  301 -> https://example.com/tags/Azure/
  200

For the www subdomain use a CNAME to <username>.github.io instead of A records, so you inherit any future renumbering automatically rather than repeating this exercise.

The same cause, a second symptom

GitHub Pages had been showing the following message in the Pages settings for as long as I could remember:

Enforce HTTPS — Unavailable for your site because your domain is not properly configured to support HTTPS

I had assumed it was caused by the CDN proxy sitting in front of the origin. Part of it was, but GitHub also verifies that the domain’s A records match its current address set. Deprecated addresses fail that check.