GitHub Pages IP Address: The Four A Records, the WWW CNAME, and Pointing a Real Domain at It

GitHub Pages publishes four fixed IPv4 addresses for pointing an apex domain at it: 185.199.108.153, 185.199.109.153, 185.199.110.153, and 185.199.111.153, used as A records because an apex domain, the bare example.com with no subdomain, can’t use a CNAME record the way www.example.com can. Four matching AAAA records handle IPv6. A www subdomain, or any other subdomain, should be a CNAME pointed at the username.github.io address instead of these IPs directly. Getting this wrong is the single most common reason a GitHub Pages custom domain doesn’t resolve, or resolves but never gets a certificate, so the exact records matter more than the general idea.

GitHub Pages IP address is a lookup query more than a conceptual one; most people searching it already know they need an A record, they just need the current, correct numbers, because a stale answer on an old forum post or a mismatched setting is exactly what breaks a domain that looks configured correctly. This has the current IPv4 and IPv6 values straight from GitHub’s own documentation, the difference between what the apex domain needs and what a subdomain needs, the misconfigurations that cause the most support threads, and what happens after DNS resolves: the certificate GitHub issues automatically and the HTTPS enforcement setting that depends on it.

Table of contents

• The four A records for an apex domain
• AAAA records for IPv6
• Why www uses a CNAME instead of these IP addresses
• Common misconfigurations
• What happens after DNS resolves: the certificate
• This is a DNS task, and what it leads to next
• How this fits the rest of the stack
• FAQ

The four A records for an apex domain

An apex domain, example.com with nothing in front of it, points at GitHub Pages with an A record for each of these four IPv4 addresses.

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

All four should be added, not just one; GitHub load-balances across them, and using only one address works most of the time but removes the redundancy the other three exist for. These are stable, published values from GitHub’s own custom domain documentation, not something specific to one account or repository; every GitHub Pages site pointed at an apex domain uses the same four addresses.

There is no account-specific or project-specific value hiding anywhere in the settings; every GitHub account publishing a Pages site to an apex domain points at these same four numbers, which is part of why a stale value from an old answer is such an easy mistake to copy without noticing. A DNS lookup tool showing anything other than exactly these four confirms the mismatch quickly.

AAAA records for IPv6

GitHub Pages also publishes four IPv6 addresses, added the same way as AAAA records instead of A records.

2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153

GitHub’s own guidance is to add these alongside the A records, not instead of them, specifically because IPv6 adoption is still inconsistent enough globally that relying on it exclusively would leave some visitors unable to connect at all. A DNS provider that doesn’t support AAAA records isn’t broken for this purpose; the four A records alone are enough for the domain to work, IPv6 support is additive rather than required.

Skipping AAAA entirely is a legitimate, common choice, not a misconfiguration; the domain works correctly over IPv4 alone for the overwhelming majority of visitors. Providers that do support AAAA generally offer the same simple record-adding interface used for the A records, so there’s little reason to skip it once the four values are already being entered.

Why www uses a CNAME instead of these IP addresses

A subdomain like www.example.com should be a CNAME record pointed at username.github.io, not an A record pointed at the same four IPs used for the apex. The practical reason to prefer CNAME here is that GitHub can change the IPs behind username.github.io without every site’s DNS needing an update; the CNAME insulates the subdomain from that, where a hardcoded A record wouldn’t be.

Type   Name   Value
CNAME  www    username.github.io

Apex domains use A records specifically because the DNS standard doesn’t allow a CNAME record at the zone apex alongside the other records, such as MX and NS, a domain typically needs there; this is a DNS protocol limitation, not a GitHub one. Some DNS providers offer an ALIAS or ANAME record type as a workaround that behaves like a CNAME but is legal at the apex; where available, that’s a reasonable alternative to hardcoding the four IPs. Both the apex and www should ultimately serve the same content for most sites, which usually means configuring a redirect from one to the other inside the Pages settings rather than maintaining two separately updated copies of the same site.

Common misconfigurations

• Using only one A record instead of all four: works intermittently, loses the redundancy the other three provide.
• Pointing the apex at username.github.io with a CNAME: invalid at most DNS providers, since CNAME isn’t allowed at the zone apex alongside other required records.
• Old or partial IP lists copied from a stale tutorial: GitHub has changed these addresses before; a value from an old blog post or forum answer may not match the current four.
• Missing the CNAME file in the repository: the DNS side can be perfect and the site still won’t verify without a CNAME file, or the domain field in Pages settings, matching the domain on the DNS side.
• Leaving the proxy on if a DNS or CDN provider sits in front: a proxying DNS provider can serve its own IP instead of passing the request to GitHub’s, which breaks the domain verification GitHub performs before issuing a certificate.

Most of these show up as either the domain simply not resolving, or resolving but GitHub’s Pages settings showing an unverified or pending state indefinitely; checking the actual DNS records against the four values above is usually faster than guessing.

What happens after DNS resolves: the certificate

Once GitHub can see the domain correctly pointed at its IPs, it requests and issues a TLS certificate automatically, nothing to configure, no certificate file to upload. This typically takes anywhere from a few minutes to a few hours after DNS first resolves correctly, since GitHub needs to see the domain resolving before it can request the certificate, and certificate issuance itself takes a little time on top of that.

Until the certificate is issued, the Enforce HTTPS checkbox in the repository’s Pages settings stays unavailable; it only appears once GitHub has a certificate to enforce. Turning it on once it’s available forces every request to HTTPS, which is worth doing for anything beyond a temporary test, since serving the same content over both HTTP and HTTPS with no redirect leaves mixed-content and duplicate-URL issues sitting on the table for no reason.

If the certificate hasn’t appeared after several hours and the DNS records check out against the values above, removing and re-adding the domain in the Pages settings forces GitHub to re-check the DNS and re-attempt issuance, which resolves most lingering cases.

This is a DNS task, and what it leads to next

Everything above is DNS configuration, not a domain purchase; we don’t sell or register domains, and nothing here requires that we did. What we do host is what a domain points at once it’s registered somewhere: custom domains and certificates work the same way for a static site whether it started on GitHub Pages or moved to a platform that handles the domain, DNS records and certificate the way this post just walked through for GitHub’s specific case.

For the broader GitHub Pages setup this domain eventually plugs into, the repository settings, the build source, the branch, Getting Started With GitHub Pages covers that from the beginning. If the site is built with a static site generator rather than plain HTML, Hugo on GitHub Pages walks through a generator-based build reaching the same domain setup, and GitHub Pages SEO covers what a correctly resolving custom domain does and doesn’t fix for search visibility.

How this fits the rest of the stack

The four A records, the four AAAA records, and a www CNAME are the entire DNS side of this; there’s no account-specific value to look up, no dashboard to check for a personal IP, just the same published addresses every GitHub Pages custom domain uses. Once DNS resolves, the certificate and HTTPS enforcement follow within a few hours without any manual step.

The domain doesn’t have to end at GitHub Pages, either. The RunxBuild hosting calculator shows what the same custom domain, DNS records and certificate look like pointed at a static site with more room to grow than plain HTML pages alone, if the project ever needs that.

Useful related references:

• GitHub Pages SEO: What You Can Fix and What You Cannot
• GitHub Pages Does Not Support PHP, and Here Is What To Do Instead
• Getting Started With GitHub Pages, and the Exact Point You Outgrow It
• Custom domains and certificates on RunxBuild

FAQ

What is the GitHub Pages IP address?

GitHub Pages publishes four IPv4 addresses for apex domains: 185.199.108.153, 185.199.109.153, 185.199.110.153, and 185.199.111.153. Add all four as separate A records rather than just one, since GitHub load-balances across them and using only one removes the redundancy the others provide. These are the same for every GitHub Pages site pointed at an apex domain, not specific to any one account.

Should I use an A record or a CNAME for GitHub Pages?

An apex domain, example.com with no subdomain, needs the four published A records, since DNS doesn’t allow a CNAME at the zone apex. A subdomain like www.example.com should instead be a CNAME pointed at username.github.io, which lets GitHub change its underlying IPs without every site’s DNS needing an update. Mixing these up, a CNAME at the apex, or an A record for www, is a common source of DNS errors.

Does GitHub Pages support IPv6?

Yes, with four published AAAA records: 2606:50c0:8000::153, 2606:50c0:8001::153, 2606:50c0:8002::153, and 2606:50c0:8003::153, added the same way as the A records but for IPv6. GitHub recommends keeping the A records alongside them rather than relying on IPv6 alone, since IPv6 adoption is still inconsistent enough globally that some visitors would otherwise be unable to connect.

Why isn’t HTTPS working after I added my custom domain to GitHub Pages?

GitHub only requests a certificate after it can see the domain resolving correctly to its published IPs, which can take a few minutes to a few hours after DNS first propagates. Until then, the Enforce HTTPS setting in the repository’s Pages settings stays unavailable. If it’s been longer than that, recheck the DNS records against the exact four A record values rather than a copy from an older source.

Why does my GitHub Pages domain show as unverified even though DNS looks right?

The most common causes are a DNS provider proxying the domain instead of passing requests straight through to GitHub’s IPs, a missing or mismatched CNAME file in the repository, or an incomplete set of A records with only one or two of the four added. Checking the live DNS records with a lookup tool against the published values usually finds the mismatch faster than re-reading the Pages settings.