You have PageMotor running on your own VPS and a domain sitting at a registrar. This is the DNS side of connecting the two: the records to add, the stale ones to delete, and the order that keeps Let's Encrypt happy if Cloudflare is in front.
SSH in and ask the server itself, rather than trusting a hosting panel that may show an internal or floating address:
curl -4 icanhazip.comThe address it prints is the one every record below points to. Throughout this guide the example 203.0.113.10 stands in for it.
Sign in at your registrar (or wherever the domain's DNS is hosted, if you have moved it) and open the DNS settings for the domain. Add two records of type A:
| Type | Name / Host | Points to |
|---|---|---|
| A | @ (the bare domain itself) | 203.0.113.10 |
| A | www | 203.0.113.10 |
@ or www, pointing at an old host or a parking page, edit those rather than adding duplicates. Two A records with different addresses on the same name means visitors are split between the two servers at random.
Leave the TTL at the panel's default, or drop it to 300 seconds if you expect to move the site again soon. Do not touch MX, TXT or any other record types: those carry email and verification, and this job does not involve them.
While you are in the panel, look for AAAA records on @ and www. These are the IPv6 equivalents of A records, and previous hosts, parking pages and site builders love to leave them behind.
They matter more than they look. A modern browser that sees both an AAAA and an A record will usually try the IPv6 address first. If that AAAA still points at the old host, a chunk of your visitors quietly land on the old site, or on a connection error, while your own tests over IPv4 look perfect. Let's Encrypt does the same thing: its validation servers prefer IPv6 when an AAAA record exists, so a stale AAAA can fail certificate issuance even though the A record is correct.
@ and www.curl -6 icanhazip.com answers, and nginx listens on [::]:443): keep or add AAAA records pointing at that address. Wrong is worse than missing here, so only keep an AAAA you have verified yourself.Skip this step if Cloudflare is nowhere in your DNS chain. If it is, each record in the Cloudflare DNS panel has a cloud toggle: orange means proxied through Cloudflare's network, grey means DNS only, pointing straight at your server.
Set both records to the grey cloud (DNS only) before you request a certificate. Let's Encrypt's HTTP-01 challenge works by fetching a file from http://yourdomain.com/.well-known/acme-challenge/… on the machine the domain resolves to. With the proxy on, that request lands on Cloudflare's edge instead of your server, and edge-side rules, especially an Always Use HTTPS redirect, can break the challenge before your server ever sees it. Grey cloud removes the whole class of problem.
With the records grey and resolving (see checking it worked), issue the certificate on the server for both names. With certbot and nginx that is:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.comRunning CloudPanel instead? It issues Let's Encrypt certificates from its own interface, and the same rule applies: grey cloud first. The CloudPanel guide covers where that button lives.
Renewals reuse the same challenge, so if you stay grey-clouded there is nothing more to do. If you move on to step 5, certbot's nginx installation keeps renewals working through the proxy in most setups, but check the first renewal (sudo certbot renew --dry-run) rather than assuming.
Once the certificate is installed and the site loads over HTTPS, you can flip both records back to the orange cloud if you want Cloudflare's caching and DDoS protection in front. One setting decides whether that works or loops: SSL/TLS mode, under SSL/TLS in the Cloudflare dashboard.
ERR_TOO_MANY_REDIRECTS. Never use Flexible on a server that has its own certificate, which after step 4 is your server.Perfectly happy without the proxy? Grey cloud is a complete, production-fine end state. Plenty of PageMotor sites run DNS-only forever.
From your own machine, not the server:
dig +short yourdomain.com A
dig +short www.yourdomain.com A
dig +short yourdomain.com AAAA
curl -I https://yourdomain.comThe first two should print your server's address (or Cloudflare edge addresses once the proxy is on). The AAAA query should print nothing, unless you deliberately kept an IPv6 record in step 3. The curl should return HTTP/2 200 or a sensible redirect to your canonical address, not a certificate error and not a chain of redirects.
DNS changes are not instant: your registrar has to publish them and resolvers cache the old answer until the TTL runs out. Minutes is typical, a few hours is possible. dig against a public resolver (dig @1.1.1.1 yourdomain.com) shows you the published state rather than your machine's cache.
Usually the right answer at this stage rather than a fault: the document root is empty, so there is nothing to serve and the server refuses to list the folder instead. An error page generated by your server is itself proof the domain now reaches it, and the 403 clears the moment PageMotor is installed. To confirm the whole chain before installing anything, put an index.html holding a single line of text in the document root and load the site. Your text appearing means DNS, hosting and the certificate are all behaving.
If the 403 survives that test, check two things in order. First the file's size in your file manager: 0 bytes means the editor never wrote anything, because cPanel's editor (and most others) commit only when you click Save Changes. Second, the browser may be replaying a cached copy of the earlier 403, so retest in a private window or append ?test=1 to the address. A 403 that survives a genuinely fresh request against a non-empty index page is a real server-side fault: confirm the document root is the folder you think it is, that it is readable (755 on directories, 644 on files), and that no stray .htaccess above it denies access.
Cloudflare SSL/TLS mode is on Flexible while your server redirects HTTP to HTTPS. Set it to Full (strict). If you have no certificate on the server yet, that is the real problem: grey-cloud the records and do step 4 first.
Three usual causes, in order of likelihood. A stale AAAA record is still published, so validation went to the wrong machine over IPv6: back to step 3. The record is orange-clouded, so the challenge hit Cloudflare's edge instead of your server: grey cloud, retry, then flip back. Or DNS simply has not propagated yet: confirm with dig @1.1.1.1 before retrying, because failed attempts count against Let's Encrypt's rate limits.
Either the old A record was left in place alongside the new one, so visitors are split between two servers, or a stale AAAA is winning over your correct A record, or your resolver is still serving the cached old answer. Check all three with the dig commands above; the published records must show only your server.
Usually the certificate covers only one name. Step 4's certbot command requests both -d names deliberately; reissue with both if you only asked for one. If the failure is DNS rather than TLS, the www A record is missing or still pointing elsewhere.