Verification Failed 1107 | Fix Common Causes Fast

If you’re setting up CapRover and you hit “Error Code: 1107 Message: Verification Failed,” you’re in a very specific kind of stuck. Your server can be up. The CapRover dashboard can load. Still, the verification step fails and blocks setup, custom domains, or HTTPS.

This error almost always comes down to one thing: CapRover’s verification request can’t reach the expected domain endpoint the way CapRover expects. That can happen even when a browser “seems fine,” since browsers cache DNS, auto-upgrade to HTTPS, and tolerate odd redirects that automation won’t tolerate.

This walkthrough stays practical. You’ll check DNS the right way, confirm ports and firewall rules, spot Cloudflare proxy traps, and fix HTTPS validation blockers. You’ll also get a short end checklist so you can stop guessing and move on.

What Verification Failed 1107 means in CapRover

CapRover verifies that your root domain and wildcard subdomains resolve to your server. During setup, it wants to see that requests to your domain land on the CapRover server you told it about. If CapRover can’t confirm that mapping, it stops with error 1107.

In plain terms, CapRover is asking: “When I reach this domain over the public internet, do I arrive at the server IP I’m configuring?” If the answer is unclear, it fails fast.

You’ll see this error in a few common moments:

• Root domain setup — The CLI can’t confirm that *.yourdomain.com points at your server.
• Adding a custom domain to an app — The app domain doesn’t route into the CapRover ingress the way it should.
• Enabling HTTPS — Let’s Encrypt validation can’t complete, often due to port 80 or proxy settings.

CapRover’s own troubleshooting notes call out DNS and proxy settings as top causes, and it also documents a last-resort “skip verification” option when loopback checks can’t work in your network design. You can read that page here: CapRover troubleshooting.

Verification Failed 1107 during CapRover domain setup

Start with the checks that fix most setups in minutes. Don’t change five things at once. One clean change, then retest.

Check the domain records that CapRover expects

For a typical CapRover install, you want two DNS records:

• A record for the root — captain.yourdomain.com (or your chosen root) points to your server public IPv4.
• Wildcard record — *.captain.yourdomain.com points to the same server public IPv4.

Some DNS providers want the wildcard as an A record. Some let you use a CNAME to the root. Both can work, as long as the end result resolves to your server IP on public resolvers.

Use a public DNS check, not your local cache

Your laptop’s DNS cache can lie to you after a change. A public resolver check shows what the internet sees. A quick test site can help, then confirm with terminal tools like dig or nslookup on a different network.

Symptom you see	Likely cause	Fix to try first
Root works, wildcard fails	Wildcard record missing or wrong	Add or correct *.root A/CNAME
Resolves to old server IP	DNS not propagated or cached	Lower TTL, wait, recheck public DNS
IPv6 resolves, IPv4 wrong	AAAA record points elsewhere	Fix AAAA or remove it for now
Works in browser, fails in CLI	Proxy or redirect path differs	Disable proxy, confirm port 80 reachability

If you use Cloudflare, pay close attention to proxy status on the records used for verification. Cloudflare’s docs note that some verification records should be set to DNS-only (grey cloud) rather than proxied (orange cloud). This matters a lot for CapRover checks. Reference: Cloudflare proxy status and Cloudflare CNAME verification troubleshooting.

Confirm the server IP you entered is the public IP

CapRover setup asks for the server IP. If you enter a private address (10.x, 192.168.x, 172.16–31.x) or an internal load balancer IP, verification will fail. Make sure you’re using the server’s public IPv4 that the domain resolves to.

If you’re behind a load balancer, you may need to point DNS at the load balancer, then route traffic to CapRover correctly. That setup can work, but it adds moving parts. If you just want setup to pass, start direct-to-server first, then add the balancer after things are stable.

Fix DNS and propagation issues that trigger 1107

DNS looks simple until it’s not. Tiny record mistakes are enough to trip CapRover’s verification.

Fix the root and wildcard records in the same zone

Make sure the domain you’re verifying is managed by the DNS provider you’re editing. If you have a stray NS record or delegated subdomain, you can edit records all day and nothing changes publicly. Cloudflare calls this out as a common cause in verification failures when authority isn’t where you think it is. The same pattern breaks CapRover checks.

• Confirm authoritative nameservers — Use a public DNS lookup to verify which nameservers answer for your root.
• Check for delegated subdomains — Remove stray NS records that hand off control unless you truly need them.
• Align root and wildcard — Both should resolve to the same public destination.

Watch out for proxy “help” that blocks verification

Proxies can rewrite behavior in a way that breaks verification. Cloudflare’s proxy (orange cloud) is the biggest one people trip over. Cloudflare’s own docs mention that records used to verify a third-party service often should not be proxied. CapRover falls into that category during setup and domain checks.

• Set DNS-only temporarily — Turn the cloud grey for the records CapRover checks.
• Retest setup — Run the CapRover verification again after DNS-only is active.
• Re-enable proxy later — After setup, you can test proxy-on again, one record at a time.

If you need a direct quote-style reference for the idea that proxying can break verification records, Cloudflare’s docs cover it under proxy status and CNAME verification troubleshooting: proxy status, CNAME verification troubleshooting.

Open the ports CapRover and Let’s Encrypt need

Even with perfect DNS, closed ports will block verification and HTTPS enablement.

Confirm inbound access on ports 80 and 443

CapRover’s web routing and Let’s Encrypt’s HTTP validation rely on port 80 being reachable from the public internet. Port 443 matters for HTTPS traffic, yet port 80 still matters for certificate issuance in many setups.

Let’s Encrypt explicitly recommends keeping port 80 open for HTTP-01 validation on general web servers. Reference: Let’s Encrypt: allow port 80.

1. Allow TCP 80 inbound — Open it in your cloud firewall, security group, or provider firewall panel.
2. Allow TCP 443 inbound — Open it the same way, then confirm it’s routed to the server.
3. Test from outside your network — Use a phone on cellular data to hit http://your-domain and https://your-domain.

Check the “hidden firewall” layers

It’s common to open ports in one place and forget the other. Many stacks have two or three gates.

• Cloud provider rules — Security groups, VPC firewall rules, or droplet firewalls.
• Server firewall — UFW, firewalld, iptables, nftables.
• ISP blocks — Some residential networks block inbound 80/443.

If you suspect port 80 is blocked upstream, you can still run CapRover, but HTTPS issuance may require DNS-based validation routes rather than HTTP-01. CapRover’s standard flow assumes HTTP reachability for checks and certificate steps, so the easiest path is still: open 80, validate, then redirect to HTTPS.

Fix HTTPS enablement failures that look like 1107

A lot of people first meet 1107 while enabling HTTPS for a root domain or an app domain. In that case, the failure often comes from validation traffic not reaching the right place.

Make sure HTTP reaches CapRover before you request a cert

Even if you plan to force HTTPS, the certificate authority may start on HTTP validation. Let’s Encrypt points out that blocking port 80 is a common reason HTTP-01 challenges fail. Their own guidance is clear: keep port 80 available and redirect to HTTPS as needed after validation. Reference: Let’s Encrypt: allow port 80.

1. Load your domain over http — Confirm you get a response, not a timeout.
2. Disable proxy for the cert step — Set Cloudflare to DNS-only for the involved records during issuance.
3. Retry HTTPS in CapRover — Re-run enablement after the checks pass.

Spot redirects that break validation

Some validation paths fail when traffic is redirected to a different hostname, a different port, or a different service. Keep the path simple while you issue the cert. After you have a working cert, you can restore your preferred redirect rules and proxy settings.

If you’re using Cloudflare, confirm you are not running settings that interfere with validation routing while proxied. Start with DNS-only, finish setup, then test proxy-on again with care.

Run a tight troubleshooting loop when it still fails

If you’ve done DNS, ports, and proxy status, and you still see the same error, run a short loop that isolates where the mismatch lives.

Confirm what the internet sees for your domain

1. Query public DNS resolvers — Use dig against 1.1.1.1 and 8.8.8.8 to confirm the A/AAAA answers match your server.
2. Check wildcard resolution — Resolve a made-up subdomain like test123.rootdomain and confirm it lands on the same IP.
3. Verify HTTP reachability — From a remote network, confirm port 80 responds at the domain.

Confirm CapRover can serve the expected landing page

CapRover verification often expects that hitting a subdomain routes into the CapRover ingress and returns a CapRover-managed response. If your server returns a different service on port 80, verification can fail even when DNS is correct.

• Remove other listeners — Make sure another web server is not binding to port 80 in a way that bypasses CapRover.
• Check reverse proxy stacks — If you run Nginx in front, confirm it forwards traffic into CapRover correctly.
• Retest after each change — One change, one test, then move on.

Use skip verification only when your setup makes verification impossible

Some network designs break loopback checks even when everything works for real users, like certain load balancer designs or split-horizon DNS. CapRover documents a config override that can skip domain verification in those cases. Read the official notes before using it: CapRover troubleshooting.

Use that path only when your traffic is genuinely correct and you can prove it with external checks. Skipping verification can hide real DNS mistakes, and those mistakes will come back when you try to issue certificates or route app domains.

Checklist to clear 1107 and keep it from coming back

Use this as your last pass. It’s short on purpose, and it catches the repeat offenders.

1. Match DNS to the public IPv4 — Root and wildcard resolve to the same public IP on public resolvers.
2. Keep proxy off during setup — Set Cloudflare records to DNS-only for verification and certificate issuance.
3. Open port 80 and 443 — Confirm inbound rules at the provider and on the server.
4. Test from outside your LAN — Use cellular data to load the domain over HTTP and HTTPS.
5. Remove conflicting web servers — Nothing else should intercept port 80 traffic away from CapRover.
6. Retry CapRover steps after each fix — Don’t batch changes, or you won’t know what worked.

If you want one reference page to keep bookmarked, CapRover’s troubleshooting page calls out domain verification pitfalls and includes the override option for rare cases: CapRover troubleshooting. For Cloudflare-specific proxy behavior that can disrupt verification records, Cloudflare’s proxy status docs are the cleanest reference: Cloudflare proxy status. For the port 80 requirement that breaks many certificate attempts, Let’s Encrypt’s guidance is direct: Let’s Encrypt: allow port 80.

Once verification passes, you can tighten things back up: restore proxy features if you want them, add redirects, and lock down your firewall while still keeping HTTP reachable where your certificate flow needs it. The goal is simple: keep routing predictable for automation, not just for a forgiving browser.