Hostnameverificatie
Bewijs met een DNS TXT-record of een HTTPS-bestand dat je een domein beheert, zodat je het mag opwarmen.
9 min leestijd
Voordat Cache Rocket ook maar één request naar een domein stuurt, moet je aantonen dat je het beheert. Deze pagina behandelt beide verificatiemethodes en wat je doet als er één mislukt.
Hostnames staan onder Account → Hostnames.
Waarom dit verplicht is
Een cache-warmer is een machine die heel snel veel requests naar een website stuurt. Dat is nuttig als hij op je eigen server gericht is, en vijandig als hij op die van iemand anders gericht is — het is dan feitelijk een DDoS-middel.
Verificatie is wat die twee scheidt. Het betekent dat elk request dat Cache Rocket namens jou stuurt naar infrastructuur gaat waarvan je aantoonbaar hebt bewezen dat je die beheert. Je kunt er niet van afzien, en geen enkel plan haalt deze eis weg.
Note
Dit beschermt jou ook. Niemand anders kan een warmer op jouw domein richten, want zij kunnen de verificatie niet doorstaan.
Een methode kiezen
| DNS TXT-record | HTTPS-bestand of meta-tag | |
|---|---|---|
| Je hebt toegang nodig tot | Je DNS-provider | De bestanden of templates van je site |
| Gebruikelijke wachttijd | Minuten tot een uur, voor propagatie | Zo snel als je kunt deployen |
| Beste bij | Je beheert DNS en wilt een wijziging die deploys overleeft | Je deployt een app maar beheert geen DNS |
| Past goed bij | Traditionele hosting, cPanel, eigen servers | Next.js, Vercel, Netlify, statische hosts |
Beide methodes leiden tot dezelfde geverifieerde status. Kies degene die jij het snelst kunt uitvoeren.
De juiste hostname kiezen
Dit is de meest voorkomende bron van verwarring, dus het is de moeite waard om precies te zijn. Een hostname is exact het domeingedeelte van je URL's. Dit zijn allemaal *verschillende* hostnames wat verificatie betreft:
example.com
www.example.com
shop.example.com
blog.example.comVerifieer degene die in de entry-URL's staat die je wilt gebruiken. Verwijst je site example.com door naar www.example.com, dan moet je entry-URL de www-variant zijn, en dus ook de hostname die je verifieert.
Meerdere subdomeinen? Verifieer elk afzonderlijk. Er is geen wildcardverificatie.
Tip
Weet je niet welke vorm je site gebruikt? Open hem in een browser en kijk naar de adresbalk zodra hij klaar is met laden. Wat daar staat, na eventuele redirects, is de hostname die je verifieert.
Methode A — DNS TXT-record
- 1
Voeg de hostname toe
Typ op Account → Hostnames het domein en kies DNS TXT-record als verificatiemethode.
- 2
Start de verificatie
Klik op Verificatie starten. Cache Rocket genereert een unieke token en toont je de recordnaam en de exacte waarde die je moet publiceren.
- 3
Maak het record aan bij je DNS-provider
Log in waar je DNS beheerd wordt — Cloudflare, je registrar, het controlepaneel van je host — en voeg een nieuw TXT-record toe met de weergegeven naam en waarde. Kopieer en plak de waarde; typ die niet over.
- 4
Wacht op propagatie
DNS-wijzigingen zijn niet direct actief. Een paar minuten is gebruikelijk; tot een uur is normaal als je provider een lange TTL gebruikt.
- 5
Klik op Verifiëren
Klik in Cache Rocket op Verifiëren naast de hostname. Mislukt het, wacht dan langer en klik opnieuw — opnieuw proberen kost niets en zet niets terug.
Zelf het record controleren
Blijft verificatie mislukken, controleer dan eerst of het record echt zichtbaar is vanaf het publieke internet, voordat je aanneemt dat het aan Cache Rocket ligt:
dig +short TXT _cacherocket.example.comResolve-DnsName -Type TXT _cacherocket.example.comVervang de recordnaam door die Cache Rocket je toonde. Geeft het commando niets terug, dan is het record nog niet doorgekomen of niet goed opgeslagen.
Veelgemaakte DNS-fouten
Providers verschillen in of ze de volledige recordnaam verwachten of alleen het subdomeingedeelte — _cacherocket.example.com invoeren waar de provider je domein al toevoegt levert _cacherocket.example.com.example.com op. Let ook op automatisch toegevoegde aanhalingstekens en op witruimte aan het eind bij plakken.
Methode B — HTTPS-bestand of meta-tag
Kies HTTPS-bestand of meta-tag en klik op Verificatie starten. Cache Rocket toont dan drie dingen: de URL die gecontroleerd wordt, de exacte inhoud die die URL moet teruggeven, en een gelijkwaardige <meta>-tag. Je publiceert óf het bestand óf de meta-tag, niet beide.
Het bestand publiceren
Maak een bestand aan op het weergegeven pad, met exact de weergegeven inhoud en niets anders. In een Next.js-project betekent dat het in je map public/ zetten:
public/
└── .well-known/
└── cacherocket-verification.txtDeploy, en open daarna de verificatie-URL in een browser. Je hoort alleen de token te zien. Zie je je 404-pagina, opgemaakte HTML of een redirect, dan is het nog niet goed gepubliceerd.
Of via de meta-tag
Is bestanden toevoegen lastig, zet dan de meegeleverde <meta>-tag in de <head> van je homepage. In de Next.js App Router kan dat via de metadata-export:
export const metadata = {
other: {
'cacherocket-site-verification': 'JOUW_TOKEN_HIER',
},
};Deploy en klik daarna op Verifiëren.
Het bestand moet publiek bereikbaar zijn
Zit je site achter HTTP-basisauthenticatie, een IP-whitelist, een staging-wachtwoord of een “binnenkort online”-pagina, dan kan Cache Rocket het verificatiebestand niet lezen. Geef publieke toegang tot dat ene pad, of gebruik de DNS-methode.
Na de verificatie
De hostname toont Geverifieerd in je lijst en kan direct gebruikt worden in entry-URL's van zowel cache-warmers als API-warmers.
Je kunt het TXT-record of verificatiebestand daarna veilig verwijderen, maar laten staan is eenvoudiger — dan is opnieuw verifiëren direct klaar als dat ooit nodig is.
Een hostname verwijderen
Een hostname verwijderen breekt de bijbehorende warmers
Elke warmer met entry-URL's op die hostname gaat falen, omdat de URL's niet meer naar geverifieerde infrastructuur wijzen. Verplaats of verwijder die warmers eerst, of verifieer de hostname opnieuw om ze te herstellen.
Verificatie blijft mislukken
- Ik heb het DNS-record toegevoegd maar verificatie mislukt nog steeds.
- Bijna altijd propagatie. Controleer met het
dig-commando hierboven of het record publiek zichtbaar is. Vindtdighet wel en Cache Rocket niet, kijk dan of het domein dubbel in de recordnaam staat, of er een tweede conflicterend TXT-record op dezelfde naam staat. - Het verificatiebestand opent goed in mijn browser, maar Cache Rocket kan het niet lezen.
- Je browser is misschien ingelogd waar Cache Rocket dat niet is. Probeer de URL in een privévenster. Controleer ook of hij via
httpszonder redirect geserveerd wordt, en of de response platte tekst is en geen HTML-pagina met de token erin. - Welke hostname verifieer ik als mijn site doorverwijst?
- De bestemming — de hostname die in de adresbalk staat nadat de redirect klaar is. Dat is degene die je entry-URL's moeten gebruiken.
- Moet ik elk subdomein verifiëren?
- Ja. Elke hostname wordt afzonderlijk geverifieerd, en er is geen wildcardoptie.
shop.example.comheeft eigen verificatie nodig, ook alsexample.comal geverifieerd is. - Kan ik een domein verifiëren dat ik voor een klant beheer maar niet bezit?
- Ja, mits je een DNS-record kunt toevoegen of een bestand kunt publiceren — dat is precies wat de verificatie test. Bureaus verifiëren doorgaans elke klant-hostname binnen de workspace van die klant. Zie Teams en rollen.
- Kan ik een
localhostof intern adres opwarmen? - Nee. Cache Rocket warmt op vanaf het publieke internet, dus de hostname moet publiek te resolven en bereikbaar zijn.