Pages custom domain: NotServedByPagesError despite correct DNS; TLS stuck

[lastpeek]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Problem

GitHub Pages rejects a custom domain with NotServedByPagesError, while authoritative and public DNS return the documented Pages records. TLS remains at 1 of 3 — Certificate Requested, and Enforce HTTPS is disabled.

• Domain: nggpk-zameny.ru
• Alternate name: www.nggpk-zameny.ru
• Public repository: https://github.com/lastpeek/zameny-pages-connectivity-test
• Deployment source: GitHub Actions, static export.

Existing diagnostic results

These observations were collected on 2026-11-01 around 05:42–05:44 UTC; this post does not claim a fresh test.

Both ns1.reg.ru and ns2.reg.ru return exactly these apex A records (TTL 86400):

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

www has only CNAME lastpeek.github.io. There are no conflicting local A/AAAA records. The apex has no AAAA or CAA records; CAA at the www CNAME target permits letsencrypt.org.

The .ru delegation and child NS records agree on ns1.reg.ru / ns2.reg.ru. Both authoritative servers have SOA serial 1793463141. The parent DS response is NOERROR with no DS, and the child has no DNSKEY. Queries through 1.1.1.1, 8.8.8.8 and 9.9.9.9 return NOERROR with the expected apex A records and www CNAME, not SERVFAIL.

HTTP returns 200 and serves the site. HTTPS on both names fails hostname verification: the edge serves a shared GitHub certificate without this custom domain. GitHub Status reported Pages operational with no active incident at the time of these observations.

What Pages itself returns

Read-only panel GET /settings/pages/domain_status returns HTTP 200, with:

data-domain-state="both_invalid"
Both nggpk-zameny.ru and its alternate name are improperly configured
Domain does not resolve to the GitHub Pages server. (NotServedByPagesError)

The diagnostic <pre> is empty: no underlying resolved IP, resolver error or ACME details are shown. The certificate_status GET returns 1 of 3 — Certificate Requested: This domain was recently added. The certificate request process will begin shortly.

Following the documented troubleshooting step, the domain was removed and re-added exactly once, approximately 2026-11-01 04:20:30 UTC. The same error persisted afterward. We have stopped repeating that operation or changing DNS speculatively.

Question

What specific condition can make the Pages checker return both_invalid / NotServedByPagesError with this DNS configuration? Is there another read-only diagnostic that reveals the failing validation step, or a targeted correction supported by these results?

This is a technical configuration question, not a request to escalate a support ticket. No private logs, account contact details, credentials or session data are included.

[MrAbdulSamadDEV]

Hi @lastpeek — excellent diagnostics, that write-up narrows it down a lot. Since your DNS is verifiably correct, here's what's most likely going on:

both_invalid / NotServedByPagesError doesn't only mean "DNS is wrong". The Pages domain checker has two halves: (1) the domain resolves to the Pages IPs, and (2) the Pages deployment itself claims that custom domain — via a CNAME file in the published artifact. Your DNS passes (1), so the prime suspect is (2).

With a GitHub Actions deployment source, (2) is the classic failure point. DNS can be perfect, but if the deployed artifact doesn't contain a CNAME file holding nggpk-zameny.ru, the Pages edge won't serve the domain and the checker reports NotServedByPagesError for both names. Quick way to verify:

curl -s https://lastpeek.github.io/CNAME
# should print: nggpk-zameny.ru

If that returns 404 or the wrong name, check your workflow: with a static export deployed via GitHub Actions, the CNAME file must be copied into your build output (e.g. the public/ folder) before actions/upload-pages-artifact runs. Removing and re-adding the domain in Settings → Pages sets it in the UI, but for Actions-based deployments the CNAME file in the artifact is what the edge actually reads — so make sure the file is in the artifact and redeploy.

About the empty diagnostic <pre> and TLS stuck at "1 of 3": the empty block strongly suggests the checker's verification pass hasn't completed a fresh cycle since you re-added the domain at ~04:20 UTC — the panel keeps showing the cached result until the next scheduled re-check. That's also consistent with TLS staying at "Certificate Requested": the Let's Encrypt request only proceeds after the domain validation passes. One more thing to keep in mind: your records have a TTL of 86400, so any resolver that cached a negative or stale answer (from before the records were finalized, or during the remove/re-add window) can keep serving it for up to a day. Your authoritative queries look right, but the checker's resolvers may still be working off a cached copy.

So the targeted plan is:

1. Verify the CNAME file is present in your deployed artifact (the curl check above) and redeploy if it isn't.
2. Then give the checker a full re-verification cycle — up to ~24 hours — before touching DNS again.

If it's still both_invalid after that, with a correct CNAME in the artifact, that points to a platform-side verification issue and would be worth raising with support. Good luck — let me know how it goes!