TLS certificate stuck provisioning for custom domain egolab.shop

[gogoqwerty2812-cmyk]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Repo: gogoqwerty2812-cmyk/marketplace
Custom domain: egolab.shop

The site serves correctly over HTTP, but the TLS certificate has been stuck
("certificate is being provisioned" / "DNS Check in progress") for 10+ days,
so I can't enable "Enforce HTTPS".

DNS matches the supported setup exactly:

• A @ -> 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153
• CNAME www -> gogoqwerty2812-cmyk.github.io
• No AAAA, no CAA, no wildcard, no conflicting records.

The domain was migrated from account igorrodionov427-creator, which no longer
claims it (no verification TXT, its Pages returns 404).

I've removed and re-added the custom domain several times with no change.
Could a GitHub staff member please manually restart certificate provisioning?

[r4venrudy]

The public DNS responses currently differ from the records listed in the question. I checked both Google Public DNS and Cloudflare's resolver on 11 October 2026:

Google:     egolab.shop A     188.114.96.7, 188.114.97.7
Google:     egolab.shop AAAA  2a06:98c1:3120::7, 2a06:98c1:3121::7
Cloudflare: egolab.shop A     104.21.50.114, 172.67.205.219

www.egolab.shop also returns Cloudflare addresses. Those are Cloudflare proxy ranges, rather than the GitHub Pages addresses. This suggests the records are orange-cloud/proxied, even if their configured content contains the correct GitHub values. The proxy can also explain why an AAAA lookup returns addresses when you have not entered any AAAA records yourself. Cloudflare explains that behavior here.

For a direct Pages provisioning check, temporarily set the relevant apex and www records to DNS only in Cloudflare. This sends visitors directly to the public GitHub Pages origin and bypasses Cloudflare's HTTP proxy features. Then verify the external results, for example:

dig @1.1.1.1 egolab.shop A +short
dig @1.1.1.1 egolab.shop AAAA +short
dig @1.1.1.1 www.egolab.shop CNAME +short

The apex A response should contain the four GitHub addresses you listed; an AAAA response should be absent or use GitHub's documented IPv6 addresses. After that is visible externally, retry the Pages domain check. GitHub documents the expected records and how removing/re-saving the domain restarts provisioning.

This identifies a DNS discrepancy worth resolving first; it does not prove whether the previous account still affects provisioning. I cannot manually restart GitHub's certificate service.

AI-assisted answer; the DNS results above were independently checked against both public resolvers.