# Point your domain at your own PageMotor server — LLM Prompt > **How to use this file:** Paste the entire contents into Claude, ChatGPT, Gemini, or any LLM as your opening message. It gives the model the whole guide, so it can walk you through it, ask where you have got to, and help when something does not behave. > > *Source: [https://documentation.elmspark.com/guides/point-your-domain/](https://documentation.elmspark.com/guides/point-your-domain/)* --- You are helping me with the following. Use this guide as your reference. Work through it with me, ask what I have already done, and help me troubleshoot. Where a step changes something on a live site, a domain, or a server, tell me what it will do and wait for me to confirm before we go on. If something here contradicts what I am actually seeing, say so rather than guessing. **What this covers:** Point a domain at your own PageMotor server: A records for @ and www, clearing stale AAAA records, and the Cloudflare grey-cloud-first path so Let's Encrypt can issue before you switch the proxy on. # Point your domain at your own PageMotor server 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. ▶ All five steps and both traps in 3 minutes 12 seconds, narrated, with captions. The exact commands are below. **Read the narration instead** **Step one.** Ask the server for its own address rather than trusting a hosting panel that might show an internal or floating one: `curl -4 icanhazip.com`. Whatever it prints is the address every record points at. **Step two.** In the DNS panel, add two A records. One named `@` for the bare domain, one named `www`, both pointing at that address. If A records already exist, edit them rather than adding a second, because two A records with different addresses on the same name splits your visitors between two servers at random. Leave MX and TXT alone. **Step three, the one that catches people.** Look for `AAAA` records on `@` and `www` and delete them unless your server genuinely serves IPv6. A browser seeing both an AAAA and an A record usually tries IPv6 first, so a stale one sends visitors to the old host while your own IPv4 tests look perfect. Let’s Encrypt prefers IPv6 too, so a stale AAAA can fail issuance even when your A record is correct. **Step four, only if Cloudflare is in the chain.** Set both records to the grey cloud, DNS only, before requesting a certificate. The challenge fetches a file from your domain over plain HTTP, and with the proxy on that request lands on Cloudflare’s edge instead of your server. Then issue the certificate for both names. **Step five, optional.** Once the certificate is installed you can flip both records back to the orange cloud. SSL/TLS mode must be **Full (strict)**. Flexible makes Cloudflare talk to your server over plain HTTP, your server redirects to HTTPS, and the browser dies with `ERR_TOO_MANY_REDIRECTS`. That is the most reported symptom of this whole process. **Checking it.** From your own machine, not the server: dig the A records for both names, dig the AAAA and expect nothing back, then curl the site and look for a clean 200 rather than a certificate error or a chain of redirects. **Two footnotes.** A domain bought through Cloudflare Registrar cannot change its nameservers, by design, and the only route out is a transfer that ICANN blocks for 60 days. And a 403 at this stage is usually correct: it means the domain reaches your server and the document root is simply still empty. ## 1 Get your server's real IPv4 address SSH in and ask the server itself, rather than trusting a hosting panel that may show an internal or floating address: ``` curl -4 icanhazip.com ``` The address it prints is the one every record below points to. Throughout this guide the example `203.0.113.10` stands in for it. ## 2 Add A records for @ and www 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` | 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. ## 3 Delete stale AAAA records, unless your server really does IPv6 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. - **Your server has no IPv6 configured** (the common case on a basic VPS setup): delete every AAAA on `@` and `www`. - **Your server does serve the site over IPv6** and you know its address (`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. ## 4 On Cloudflare: grey cloud first, then issue the certificate 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.com ``` Running CloudPanel instead? It issues Let's Encrypt certificates from its own interface, and the same rule applies: grey cloud first. The [CloudPanel guide](https://documentation.elmspark.com/guides/pagemotor-cloudpanel/) 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. ## 5 Optionally turn the proxy on, Full (strict) only 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. - **Full (strict)**: Cloudflare connects to your server over HTTPS and verifies your certificate. This is the correct setting, and the reason step 4 came first: you now have a real certificate for it to verify. - **Flexible**: Cloudflare serves HTTPS to visitors but connects to your server over plain HTTP. Your server, correctly configured to redirect HTTP to HTTPS, bounces the request back, Cloudflare fetches over HTTP again, and the browser dies with `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. ## Checking it worked 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.com ``` The 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. ## When it does not work **403 Forbidden The domain resolves but shows Forbidden** 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. **ERR_TOO_MANY_REDIRECTS The site loops instead of loading** 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. **Issuance failed Let's Encrypt cannot validate the domain** 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. **Wrong site The old host or a parking page still shows** 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. **Works bare, not www One of the two names fails** 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. --- *Generated from the guide above. If something here looks wrong, the guide is the source of truth: https://documentation.elmspark.com/guides/point-your-domain/*