Pointing a naked apex domain to a CDN is notoriously annoying because the DNS spec forbids putting a CNAME on a zone apex. When I first wired up this combination—Namecheap managing DNS, StackPath handling edge caching, and Hostinger hosting the backend—I ran straight into broken redirects, missing origin certificates, and 520 errors. Here is how to configure all three so your root domain resolves through StackPath’s edge with working end-to-end SSL.
The Apex CNAME Problem and the Architecture
Under RFC 1034, if a node has a CNAME record, it cannot have any other records. Because your root domain (like example.com) must have SOA and NS records to function, dropping a standard CNAME on the @ hostname simply fails. Most DNS dashboards will throw a hard validation error if you even try.
To bypass this without forcing every single visitor through an ugly www redirect, we have two options: Namecheap’s native ALIAS pseudo-record or StackPath’s direct Anycast IPs. The request path looks like this:
- A browser requests
example.com. - Namecheap resolves the apex request to StackPath’s Anycast edge IP pool.
- StackPath terminates the visitor’s TLS connection using an edge cert.
- On a cache miss, StackPath opens a TLS session to Hostinger using the origin IP and passes the original domain in the SNI host header.
- Hostinger’s web server answers, and StackPath caches the response on the way back out.
If you also need to route subdomains through this setup, check out our walkthrough on how to connect Namecheap DNS to StackPath CDN with Hostinger origin.
Step 1: Prep the Origin Host on Hostinger hPanel
Before touching your DNS, get your Hostinger vhost ready to accept requests for the root domain. If Hostinger does not recognize the apex hostname or lacks a valid SSL cert, StackPath will immediately throw a 502 Bad Gateway or 520 Origin Error.
Log in to hPanel and grab your shared server or VPS IP under Hosting > Manage > Plan Details. Keep that IPv4 address handy (something like 195.35.12.45).
Make sure the domain is set up as a website in your account so Hostinger creates the matching Apache or LiteSpeed virtual host. Before touching any DNS records, test whether the origin actually responds to the apex domain by hitting Hostinger’s IP directly with a curl resolve flag:
curl -Iv -k --resolve example.com:443:195.35.12.45 https://example.comYou want an HTTP/2 200 or HTTP/1.1 200. If you get a certificate error or a default 403 splash page, generate a free Let’s Encrypt certificate right inside hPanel under Security > SSL. StackPath needs a clean origin handshake when running in end-to-end HTTPS mode.
Step 2: Configure the StackPath CDN Site and Edge Origin
With Hostinger answering locally, set up StackPath to proxy it. In your StackPath portal, spin up a new Site:
- Pick CDN as the service.
- Enter your naked apex domain in Domain Name (e.g.,
example.com). - Set Origin Type to
IP Addressand paste your Hostinger IPv4. - Check HTTPS Port and set it to
443.
Once the site is created, immediately jump into CDN > Site Settings > Origin. Change the Origin Host Header to your apex domain name instead of leaving it on “Origin IP”. If StackPath sends the raw IP as the host header, Hostinger’s LiteSpeed server will not match the virtual host and will serve a blank default page or a 404.
Next, click into Certificates in StackPath. Hit Generate Certificate, add both example.com and *.example.com (or www.example.com), and choose HTTP Validation. Leave this screen open—we will complete the challenge right after updating Namecheap.
If your backend dumps session cookies onto static files, consider setting up rules to strip Set-Cookie headers for static assets in StackPath so your edge cache hit rates do not plummet.
Step 3: Configure Namecheap DNS Records for Apex Routing
Head to Namecheap, open your Domain List, hit Manage on your domain, and click into Advanced DNS.
StackPath gives you an edge delivery hostname (like your-site-id.stackpathcdn.com) alongside a pair of Anycast IPs. You have two ways to wire up the root record in Namecheap BasicDNS:
Option A: The ALIAS Record (Recommended)
Namecheap BasicDNS has an ALIAS record type built specifically for the apex node. It acts like a CNAME from your perspective, but Namecheap’s nameservers dynamically synthesize standard A records when resolving queries. This keeps RFC 1034 happy while sending all traffic to StackPath’s edge.
Add these entries to your DNS records table:
- Type:
ALIAS Record| Host:@| Value:your-site-id.stackpathcdn.com| TTL:Automatic - Type:
CNAME Record| Host:www| Value:your-site-id.stackpathcdn.com| TTL:Automatic
Option B: Static Anycast A Records
If your account tier lacks ALIAS support or you want predictable, hardcoded addresses, use StackPath’s assigned Anycast IP pairs. Add two root A records:
- Type:
A Record| Host:@| Value:151.139.128.10| TTL:5 min - Type:
A Record| Host:@| Value:151.139.128.11| TTL:5 min - Type:
CNAME Record| Host:www| Value:example.com| TTL:5 min
Wipe out any existing A records pointing directly to Hostinger’s IP or Namecheap parking pages on @. If you leave an old A record sitting there, roughly half your traffic will bypass the CDN completely.
Step 4: Fix Origin SSL Handshakes and Hostinger Auto-Renewals
Here is a trap that will bite you three months down the road: Hostinger’s Let’s Encrypt client tries to renew its origin cert via HTTP-01 challenges, but because DNS now points to StackPath, those requests hit the CDN cache and fail, taking down the origin handshake.
To stop this from breaking, tell StackPath to pass ACME challenges straight through to Hostinger without touching the cache. In StackPath, open CDN > EdgeRules and add a new rule:
- If: Request URL path matches wildcard
/.well-known/acme-challenge/* - Then: Set Cache Expiration to
0 seconds(Bypass Cache)
Then tweak your Hostinger .htaccess file (in public_html/) so its HTTPS redirect rules do not create an infinite redirect loop with StackPath’s proxy engine. Here is the block I drop in on Hostinger LiteSpeed/Apache setups:
# Ensure SSL detection works behind CDN reverse proxy
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]This checks the X-Forwarded-Proto header passed by StackPath, preventing Hostinger from redirecting already-secure sessions. If you are running an app with authentication cookies, remember to bypass CDN edge cache for logged-in WordPress users so private pages do not get cached and served to everybody.
Step 5: Test DNS Propagation and Edge Header Verification
Never rely on a regular browser tab to test this—local DNS caches and browser session state will lie to you. Use terminal tools instead.
First, verify what Namecheap is resolving for your apex:
dig @8.8.8.8 example.com A +shortYou should see StackPath’s Anycast IPs returned, not your backend Hostinger IP:
151.139.128.10
151.139.128.11Now, run a verbose curl request through the edge and inspect the response headers:
curl -Iv https://example.com/Keep an eye out for these headers specifically:
HTTP/2 200 server: StackPath
x-hw: 1684928123.dop014.pa2.t,1684928123.cds021.pa2.c
x-cache: HITIf server returns StackPath and you see an x-hw or x-cache header, your apex domain is flowing cleanly through the CDN. If the server says LiteSpeed or Apache, your DNS hasn’t updated yet or your machine is reading stale resolver cache.
For more details on how these platforms interact, read our guide on how to deploy a web app on Hostinger with Namecheap DNS and StackPath CDN.
Gotcha: Resolving 520 and 502 Origin Connection Errors
When I first spun up this stack, my www subdomain worked instantly, but the apex threw a 520 Origin Server Error. Here are the three usual culprits:
- SNI Mismatch: In StackPath’s Origin settings, if Origin SSL SNI is toggled on but Hostinger only generated a cert for
www.example.com, the TLS handshake dies right there. Make sure Hostinger’s certificate covers both the root andwww. - Hostinger IP Rate Limiting: Hostinger’s firewall can mistake high volumes of traffic coming from StackPath’s egress nodes for an attack. If your traffic spikes or drops intermittently, add StackPath’s published IP blocks to your VPS allowlist or ask Hostinger support to verify that CDN egress IPs are unblocked on your shared plan.
- Origin Port Mismatch: Make sure StackPath is connecting to Hostinger over HTTPS on port 443. If StackPath connects over HTTP (port 80) and Hostinger forces an HTTPS redirect, you will end up in a circular loop that ends in a
504 Gateway Timeout.
Frequently Asked Questions
Can I use a standard CNAME for my apex domain in Namecheap?
No. The DNS standard bans CNAME records on root zones because they conflict with SOA and NS records. Use Namecheap’s ALIAS record type or point static A records to StackPath’s Anycast IPs instead.
Will Namecheap ALIAS records break my email delivery?
No. Namecheap dynamically flattens ALIAS records into standard A records at query time. Your MX, TXT (SPF), and DKIM records at the root remain completely untouched.
Do I need an SSL certificate on both Hostinger and StackPath?
Yes. StackPath requires an Edge SSL certificate to handle visitors over HTTPS, and Hostinger needs its own certificate so StackPath can securely connect to your origin on port 443 without handshake errors.
How long does the Namecheap DNS change take to propagate?
If you set your old A record’s TTL to 300 seconds before cutting over, traffic moves to StackPath in about 10 to 15 minutes. Full propagation across stubborn regional resolvers can take up to 2 hours.
Next Steps
With your apex domain resolving through StackPath and SSL humming along nicely, take a closer look at your cache policies. Check out our walkthrough on how to connect Namecheap DNS to StackPath CDN with Hostinger origin to dial in compression rules and origin shielding.
