Kort svar: Brug normalt orange sky — Proxied — på A-, AAAA- og CNAME-poster, der leverer dit website over HTTP eller HTTPS. Brug grå sky — DNS only — til mailrelaterede hostnames, domæneverifikation, ikke-HTTP-tjenester og tredjepartstjenester, der ikke understøtter Cloudflare-proxyen. MX og TXT kan ikke proxieres. En grå webpost afslører origin-adressen og mister Cloudflare-cache, WAF og DDoS-beskyttelse, så brug den ikke som permanent fejlfinding.
Risiko: Middel Forventet tid: 10-30 minutter Hav klar: En funktionel oversigt over hver DNS-post og en eksport eller kopi til rollback
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. DNS- og proxyskellene er gennemgået fagligt; Hostious er ikke bag Cloudflare. En neutral eller syntetisk illustration af orange/grå status viser princippet, ikke en aktiv Hostious-zone.
Den farvede sky styrer ikke, om Cloudflare er din DNS-udbyder. Den styrer, om webtrafikken til den enkelte A-, AAAA- eller CNAME-post går gennem Cloudflares reverse proxy. Orange og grå er derfor et routing- og sikkerhedsvalg — ikke en generel “hurtig/langsom”-kontakt.
På denne side
Når en webpost er Proxied, svarer offentlige DNS-opslag med Cloudflare-adresser i stedet for originens adresse. HTTP- og HTTPS-requesten går gennem Cloudflare, hvor TLS, cache, WAF, redirects og andre proxyfunktioner kan anvendes.
Orange er normalt det rigtige valg for:
www, hvis det serverer eller redirecter webtrafik;En proxied post får en Cloudflare-styret TTL. En ændring kan stadig tage tid i lokale DNS-caches, selv om dashboardet er opdateret.
DNS only returnerer postens faktiske IP eller CNAME-destination. Trafikken går uden om Cloudflares HTTP-proxy. Dermed anvendes Cloudflare-cache, WAF, redirectregler og proxybaseret DDoS-beskyttelse ikke på det hostname.
Grå er normalt det rigtige valg for:
mail-hostname, der bruges til SMTP, IMAP eller POP;MX og TXT har ikke en orange/grå webproxyfunktion. Hvis en MX-post peger på mail.example.dk, skal A-/AAAA-posten for mail normalt være DNS only, ellers vil mailservere ramme Cloudflares webadresser i stedet for mailserveren.
| Spørgsmål | Ja | Nej |
|---|---|---|
| Leverer posten HTTP eller HTTPS? | Gå videre til kompatibilitet | DNS only/ikke-proxierbar |
| Er typen A, AAAA eller CNAME? | Kan normalt proxieres | Kan ikke bruge webproxy-status |
| Understøtter tredjepartstjenesten Cloudflare proxy? | Proxied er muligt | DNS only |
| Skal Cloudflare WAF/cache/redirects gælde? | Proxied | DNS only |
| Bruges hostname som mailserver eller verifikation? | Normalt DNS only | Vurder som webtrafik |
Hvis mail-hostnamet proxieres, forsøger mailklienter at forbinde til Cloudflares webproxy. Sæt den bagvedliggende A-/AAAA-/CNAME-post til DNS only, og kontrollér at MX peger på det korrekte mailhostname. Skift ikke hoveddomænets webpost, medmindre den faktisk bruges som mailserver og arkitekturen er dokumenteret.
En grå webpost kan stadig vise WordPress direkte, så det ser ud som en “løsning”. Men headers, WAF-events og cache forsvinder, og origin bliver offentlig. Gendan Proxied efter diagnosen, og ret i stedet SSL, firewall eller routingårsagen.
Nogle SaaS- og andre CDN-tjenester kræver, at deres CNAME er synlig eller håndterer TLS selv. Følg tjenestens verificerede DNS-krav og brug DNS only, hvis den ikke understøtter Cloudflare. Aktivér ikke orange blot fordi typen teknisk kan proxieres.
En proxied A og en gammel AAAA på samme hostname kan gøre diagnosen uklar. Gennemgå begge og bekræft, at IPv6-destinationen er tilsigtet. Fjern ikke AAAA uden at vide, om origin bruger IPv6; gem værdien til rollback.
Et offentligt DNS-opslag af en proxied post bør returnere Cloudflare-adresser, ikke origin-adressen. En HTTP-response gennem proxyen vil normalt have Cloudflare-relaterede headers som CF-Ray; CF-Cache-Status kan mangle eller være DYNAMIC uden at proxyen er væk.
Ved DNS only returnerer opslaget den faktiske destination. Publicér ikke outputtet, hvis det afslører origin-IP. Brug en redigeret testzone til screenshots og beskriv produktionskontrollen uden værdien.
Orange sky reducerer den direkte eksponering, men tidligere DNS-data, mailhostnames eller andre poster kan allerede have afsløret origin. Den egentlige beskyttelse er en origin-firewall, der kun tillader forventet trafik, korrekt TLS og opdateret serverdrift. Stol ikke på orange sky som eneste adgangskontrol.
Hvis du midlertidigt viser origin via DNS only, skal du vurdere, om adressen bør skiftes bagefter. Det er især relevant, hvis origin kun var beskyttet af, at adressen ikke var kendt.
En typisk zone rummer mere end “web” og “mail”. Der kan være kontrolpanel, filoverførsel, autodiscover, webhooks, statusdomæne, leverandørverifikation og underdomæner, som peger på eksterne platforme. Hver post skal have en ejer og en forventet protokol. Cloudflare-proxyen er designet til bestemte webporte og HTTP(S)-trafik; en tilfældig orange sky på en anden tjeneste kan gøre den utilgængelig.
| Funktion | Typisk beslutning | Hvad du skal efterteste |
|---|---|---|
| Offentligt website | Proxied, når origin og SSL er klar | HTTPS, redirects, headers og applikation |
| Mailhost/MX-destination | DNS only | SMTP-/leveringstest hos mailleverandøren |
| TXT-verifikation | Ingen proxyfunktion | At leverandøren kan læse den korrekte værdi |
| Ekstern SaaS-CNAME | Følg leverandørens krav | Domænevalidering, certifikat og funktion |
| Kontrolpanel eller særport | Ofte DNS only eller særskilt adgangsdesign | Login, port og sikkerhedsbegrænsning |
“Typisk” er ikke en ordre til at ændre posten. Leverandørens integrationskrav og den faktiske tjeneste er facit.
Et domæne får orange sky på mail, fordi posten ligner et almindeligt hostname. Websitet virker fortsat, men mailklienter kan ikke forbinde. Løsningen er at sætte mailhosten tilbage til DNS only og kontrollere, at MX peger på det rigtige navn. Samtidig skal du gennemgå, om origin-adressen er blevet genbrugt på en måde, der kræver en anden sikkerhedsplan. Du skal ikke gøre selve websitet gråt for at reparere mailen.
Planlæg testen som en driftshændelse: bekræft gyldigt origin-certifikat, adgangskontrol og kapacitet, notér starttid, og gendan proxyen straks. Kontroller efterfølgende DNS-svar og et ægte Cloudflare-header. En vellykket direkte side kan afgrænse problemet til proxykæden, men den fortæller ikke, om fejlen skyldes firewall, SSL, cache eller en regel.
Gendan den gemte destination og proxy-status på den ene ændrede post. DNS-cache kan forsinke oplevelsen, så brug autoritative opslag og dokumentér tidspunktet. Undgå at lave flere samtidige DNS-ændringer for at “få det til at gå hurtigere”.
Hosting skal hjælpe, når postens korrekte origin, IPv6, certifikat eller firewall er ukendt. Mailleverandøren skal bekræfte mailhostnames, mens SaaS-leverandøren skal bekræfte proxykompatibilitet. Se WordPress-hosting hos Hostious, hvis weborigin og DNS skal afstemmes samlet.
A-, AAAA- og CNAME-poster der leverer websitet over HTTP/HTTPS. Så får trafikken CDN, cache og beskyttelse – og origin-IP’en holdes skjult.
Fordi Cloudflare-proxyen kun håndterer webtrafik. En proxied post bag MX får SMTP-levering til at fejle – mail, FTP og andre ikke-HTTP-tjenester skal stå til DNS only.
Ja – DNS only offentliggør IP’en for den post. Brug derfor gerne et separat hostname (fx mail.) til de grå poster, så selve web-origin bag proxyen ikke kan udledes direkte.
Lav en funktionsliste før du ændrer en sky: hostname, recordtype, formål, leverandør, forventet port og ønsket proxy-status. Skriv “website på HTTPS” eller “SMTP-hostname” frem for blot “vigtig post”. Formålet gør det muligt at opdage, at en mail- eller verifikationspost ved en fejl er blevet behandlet som webtrafik.
Gem en zoneeksport sikkert, men brug kun en redigeret tabel i supportsager. Origin-adresser, verifikationstokens og interne hostnames hører ikke hjemme i offentlige billeder. For en proxied webpost dokumenteres DNS-svaret sammen med et CF-Ray– eller andet ægte Cloudflare-signal fra samme hostname. For DNS only dokumenteres, at den tiltænkte tjeneste stadig svarer, uden at adressen gengives offentligt.
Ved skift bør notatet have starttid, TTL, ejer, stopkriterium og rollbacktid. Eftertesten skal passe til funktionen: web kræver HTTPS og den konkrete applikation; mail kræver leverandørens forbindelses-/leveringstest; en SaaS-CNAME kræver leverandørens validering. At websitet åbner er ikke bevis for, at MX, DKIM, webhook eller verifikationsflow stadig virker.