19 nov. 2025·7 min
Felsökningschecklista för anpassade domäner vid DNS- och SSL-problem
Använd denna felsökningschecklista för anpassade domäner för att diagnostisera DNS-poster, propagationstider och SSL-timing med enkla verifieringssteg.
Använd denna felsökningschecklista för anpassade domäner för att diagnostisera DNS-poster, propagationstider och SSL-timing med enkla verifieringssteg.
”Anpassad domän fungerar inte” är ett paraplybegrepp för några olika fel. Din webbläsare visar symtomet, inte orsaken. Innan du ändrar något, skriv ner vad du faktiskt ser.
Typiska symtom inkluderar:
Oftast är det bara en sak som är fel:
Innan du felsöker, se till att du har åtkomst till två platser: där du redigerar DNS-poster (registrar eller DNS-leverantör) och där du kopplar domänen på hosting-sidan. Till exempel, om du kopplar en distribuerad app på Koder.ai till en anpassad domän behöver du DNS-åtkomst för domänen och domäninställningarna i appens hosting- eller distributionsinställning.
Vissa fixar är omedelbara (som att rätta ett skrivfel). Andra tar tid. DNS-ändringar kan ta ett tag innan de syns, och SSL slutförs vanligtvis inte förrän DNS pekar korrekt och domänen är nåbar. Målet är att sluta gissa och bekräfta varje lager i ordning.
De flesta domänproblem handlar om att något inte stämmer mellan (1) det värdnamn du testar, (2) var DNS hanteras, och (3) vad posten faktiskt pekar på. När dessa tre stämmer överens är SSL oftast sista steget.
Domäner har två vanliga former: rotdomänen (example.com, också kallad apex) och underdomäner (www.example.com, app.example.com). De är relaterade, men kan ha olika DNS-poster. Så det är normalt att www fungerar medan apex misslyckas, eller tvärtom.
Nameservers bestämmer vem som har hand om din DNS-zon. Om du köpte en domän från ett företag men nameservers pekar till ett annat måste du redigera DNS där nameservers pekar. Många ”jag uppdaterade men inget hände”-situationer uppstår för att posterna redigerades i fel panel.
Här är vad de viktigaste posttyperna gör:
TTL är timern för ”hur länge detta får cachas”. Lägre TTL betyder att cacher uppdateras snabbare. Högre TTL betyder att du kan behöva vänta längre, även efter att du rättat posten. Att se det gamla värdet en stund kan vara normalt.
När en anpassad domän misslyckas kan du vanligtvis sortera det i en av fyra kategorier: DNS löser inte, DNS löser till fel ställe, SSL är inte klart, eller det bara misslyckas för vissa personer på grund av cachning.
Använd detta beslutsträd:
www fungerar men rot-domänen inte (eller tvärtom) har du sannolikt bara konfigurerat ett värdnamn, eller så har du konkurrerande omdirigeringsregler.Arbeta snabbare genom att skriva ner det exakta värdnamnet som misslyckas (apex vs www) och det exakta felmeddelandet. På hostingplattformar som automatiserar domäner och certifikat säger skillnaden mellan ”kan inte hitta host” och ”certifikat väntar” om du ska fixa DNS-poster eller helt enkelt vänta på SSL efter att DNS blivit synligt.
Många domänfel börjar med en enkel mismatch: du satte upp DNS för ett värdnamn, men du testar ett annat.
Först, skriv ner det exakta värdnamnet du vill ha live. Rotdomänen ser ut som example.com. En subdomän ser ut som www.example.com eller app.example.com. Dessa är separata DNS-uppslag, så ”www fungerar” betyder inte att rot-domänen kommer att göra det.
Nästa steg: hitta det förväntade målet från din hostingplattform. Vissa plattformar ger en IP-adress (för en A- eller AAAA-post). Andra ger ett mål-värdnamn (för en CNAME). Om din host visar ett värde i en domäninställningsskärm, behandla det som sanningskällan.
Innan du ändrar något, fånga vad som är inställt nu. Håll det enkelt:
Bekräfta också att du redigerar rätt DNS-zon. Det är lätt att uppdatera fel domän, fel miljö eller fel konto hos en leverantör.
Många problem är helt enkelt fel posttyp för det värdnamn du försöker ansluta. Börja med att separera två fall: rotdomänen (example.com) och en underdomän (www.example.com). De beter sig olika hos många DNS-leverantörer.
En A-post pekar ett namn till en IPv4-adress. Många uppsättningar använder en A-post för rotdomänen eftersom vissa leverantörer inte tillåter en CNAME i apex. Om din host ger en IP är en A-post vanligtvis rätt.
En AAAA-post är IPv6-versionen. En vilseledande AAAA-post som pekar mot ett gammalt mål kan skapa förvirrande ”funkar för mig”-beteende, eftersom vissa besökare når IPv6 medan andra når IPv4. Om din host inte gav ett IPv6-mål, hjälper det ofta att ta bort en felaktig AAAA-post.
En CNAME pekar en underdomän till ett annat värdnamn (används ofta för www). Den är användbar när hosten vill att du ska rikta mot en namngiven endpoint som kan ändras bakom kulisserna.
En TXT-post används för verifiering och utmaningar (inklusive vissa SSL-kontroller). Vanliga misstag är att lägga TXT på fel namn (rot vs _acme-challenge vs en underdomän), lägga till extra mellanslag eller klistra in fel värde.
Innan du går vidare, leta efter konflikter. Dessa orsakar mest problem:
Många ”anpassad domän fungerar inte”-fall handlar inte om postvärdet alls. De händer för att posten lagts till hos fel leverantör. Om din domän använder Provider A:s nameservers, gör ändringar i Provider B:s panel inte något, även om posterna ser korrekta ut där.
Kontrollera vilka nameservers din domän faktiskt använder. Du kan vanligtvis se detta i din registrars domäninställningar under ”Nameservers”. För en andra åsikt, fråga DNS direkt från din dator:
dig NS example.com
Nameservers som returneras av det kommandot är de auktoritativa.
En snabb kontroll:
ns1... och ns2... måste exakt de värdena finnas hos registraren.Om du uppdaterar poster hos fel leverantör ser du ofta två paneler som inte matchar. Endast de auktoritativa nameservers spelar roll.
Titta också på fördröjningar efter att du ändrat nameservers hos registraren. Under övergångsperioden kan resultat se inkonsekventa ut beroende på var du testar från. Om nameservers fortfarande byts, paus poständringar tills nameserver-setet är stabilt, och fortsätt sedan.
”Propagation” är inte en enda strömbrytare. Det är en kedja av DNS-cacher (ISP, mobiloperatör, offentliga resolverar och dina egna enheter) som uppdateras i olika hastigheter. Därför kan din domän fungera för en kollega men misslyckas för dig.
TTL (time to live) talar om hur länge cacher får behålla ett svar. Om den gamla TTL:n var 1 timme kommer vissa att fortsätta se det gamla värdet i nästan en timme. Att sänka TTL hjälper bara om du gjorde det innan ändringen.
För att skilja cacheförseningar från riktiga misstag, gör några snabba kontroller:
Om posten är fel någonstans du kollar (fel IP, saknat www, gammal CNAME), åtgärda den. Om posterna ser korrekta ut på de flesta platser men ett nätverk fortfarande visar det gamla värdet är det vanligtvis cachefördröjning.
SSL-certifikat misslyckas vanligtvis av en grundläggande anledning: certifikatutgivaren kan inte validera domänen förrän DNS pekar till rätt ställe konsekvent.
Normal sekvens är enkel:
Vanliga hinder är lätta att missa. En felaktig A- eller CNAME-mål skickar valideringskontroller till fel server. En föråldrad AAAA-post kan åsidosätta din fungerande A-post för vissa besökare, så HTTPS misslyckas bara för dem. Att sakna en nödvändig TXT-post kan hindra plattformen från att utfärda ett certifikat.
Använd symtom för att skilja ”fortfarande utfärdar” från ”felkonfigurerat”:
Medan du väntar, byt inte poster hela tiden. Varje ändring nollställer klockan och kan skapa en splittrad värld där olika nätverk ser olika svar. Ställ in rätt poster en gång, kontrollera sedan upplösning och verifiering tills certifikatet är utfärdat.
Om du använder en plattform som Koder.ai är det säkraste flödet detsamma: bekräfta att DNS pekar på det förväntade målet, ta bort felaktiga AAAA-poster om de finns, och ge SSL tid efter att DNS är stabil.
Bra felsökning är mest jämförelse: vad du ser vs vad du förväntar dig. Lita inte på ”den laddar på min telefon”. Använd upprepbara kontroller.
Använd ett DNS-uppslagsverktyg (som nslookup eller dig) och bekräfta att det returnerade värdet matchar det du avsåg (en IP för A eller AAAA, ett värdnamn för CNAME, en token för TXT).
# Apex (rot) domän
dig example.com A
dig example.com AAAA
# www underdomän
dig www.example.com CNAME
# TXT (används ofta för verifiering)
dig example.com TXT
Kontrollera både namn du kan använda: apex (example.com) och www (www.example.com). Det är vanligt att ett av dem är korrekt medan det andra fortfarande pekar någon annanstans.
Öppna både http:// och https:// för apex och www. Du vill ha ett tydligt ”hem”-domän och en ren omdirigering.
www) och omdirigera det andra till det.Om resultat skiljer sig per nätverk är det sannolikt cachning eller propagation. För förvalta en liten logg: vad du ändrade, var du ändrade det, tidpunkt och vad du observerade.
De flesta DNS- och SSL-problem är inte mysterier. De är små misstag som får dig att kontrollera fel sak, eller ändra för snabbt för att få ett klart svar.
Det vanligaste tidsförlusterna är att redigera DNS på två ställen. Detta händer ofta efter ett nameserverbyte: du uppdaterar poster hos registraren, men DNS är faktiskt hostat någon annanstans (eller tvärtom). Allt ser korrekt ut i en panel, ändå händer inget offentligt.
Ett annat klassiskt misstag är att försöka lägga en CNAME på rotdomänen hos en leverantör som inte stödjer det. Du kan behöva en A-post, eller en ALIAS- eller ANAME-liknande post om din DNS-leverantör erbjuder det.
IPv6 kan också orsaka huvudvärk. Att lämna en gammal AAAA-post kan skicka vissa besökare till fel server medan andra når IPv4 korrekt.
Var försiktig med ”för säkerhets skull”-poster. Flera A-poster kan bete sig som oavsiktlig lastbalansering om ett mål är fel, särskilt när du pekar en anpassad domän mot en hostad app.
En sista regel: sluta nollställa klockan.
Små, lugna ändringar slår konstant pillande.
Du lanserar en ny app och sätter upp både example.com och www.example.com. Några minuter senare laddar www.example.com fint, men rot-domänen visar DNS-fel, laddar en gammal site eller HTTPS hänger kvar som väntande. Detta mönster är vanligt och brukar ha en liten orsak.
Börja med den tråkiga frågan: redigerar du DNS på rätt ställe? Om din domän är registrerad hos ett företag men DNS hostas någon annanstans kan du ändra poster hela dagen utan att något händer. Kontrollera nameservers först, öppna sedan DNS-panelen för leverantören som nameservers pekar på.
Jämför sedan de två värdnamnen. www är vanligtvis en CNAME. Rotdomänen är knepigare: många leverantörer tillåter inte CNAME i apex, så den behöver ofta en A-post till en IP, eller en ALIAS/ANAME-typ om det stöds.
En praktisk beslutsväg:
example.com saknar post (eller pekar någon annanstans)? Fixa apex-posten.Det korrekta slutläget är tråkigt: både example.com och www.example.com leder till samma app, en är kanonisk (den andra omdirigerar), och HTTPS är giltigt.
När en domäninställning misslyckas kommer de flesta fixarna från några få snabba kontroller. Kör dessa innan du ändrar något annat.
Efter att DNS är tydligt korrekt, kontrollera SSL. Många plattformar utfärdar certifikat först efter att de kan lösa din domän till rätt mål konsekvent. Om du kollar för tidigt kan du missta en normal fördröjning för ett verkligt fel.
Om du lägger till en anpassad domän till en distribuerad app på Koder.ai, använd domäninställningsskärmen som referens för det förväntade målet, och kontrollera status först efter att DNS haft tid att propagera.
Det snabbaste sättet att undvika att upprepa DNS- och SSL-misstag är att behålla en kort ”domänuppsättningsanteckning” för varje projekt. Det är en återanvändbar runbook du kan kopiera nästa gång du lanserar.
Behåll den i projektets dokumentation och fyll i innan du rör DNS:
Under lansering, utse en person som DNS-ägare. DNS går oftast sönder när två personer försöker ”fixa” olika saker samtidigt (till exempel att en ändrar nameservers medan en annan redigerar poster).
På hosting-sidan, planera för säkra återställningar. Om din plattform stöder snapshots eller rollback, ta en snapshot innan du ändrar routing så att du snabbt kan återgå till sista kända fungerande tillstånd. Om du bygger på Koder.ai kan du använda Planning Mode för att skriva ner domänstegen du ska ta, tillämpa dem i ordning och rulla tillbaka om en ändring bryter produktion.
Om du bekräftat att DNS är korrekt och du ändå ser fel, sluta gissa och eskalera med bevis:
När du eskalerar, inkludera värdnamnet, förväntade poster, aktuella resolver-resultat och tidsstämplar. Det gör en långsam fram-och-tillbaka till en snabb fix.
Det betyder oftast att ett skikt i kedjan är fel: DNS löser inte, DNS pekar till fel mål, servern/hosten känner inte igen ditt värdnamn, eller HTTPS/SSL har inte slutat utfärdas än. Börja med att skriva ner det exakta felet du ser och det exakta värdnamnet du skrev (apex vs www).
För att example.com (apex) och www.example.com är separata värdnamn med separata DNS-poster. Det är vanligt att ha en korrekt CNAME för www medan apex saknar en A-post, har fel A-post eller kräver en annan lösning hos din DNS-leverantör.
Kontrollera domänens nameservers hos din registrar och jämför dem med den DNS-leverantör du redigerar hos. Endast leverantören som listas i de aktiva nameservers är auktoritativ; att redigera poster någon annanstans ändrar inte vad internet ser.
Använd en A-post när din host ger en IPv4-adress, en AAAA-post bara om din host ger en IPv6-adress, och en CNAME när din host ger ett annat värdnamn (vanligast för www). TXT-poster används för verifiering och utmaningar och måste skapas på det exakta namn din host anger.
En föråldrad eller felaktig AAAA-post kan skicka vissa besökare över IPv6 till en gammal server medan andra når rätt IPv4-adress, vilket skapar ”fungerar för mig”-konfusion. Om din host inte gav ett IPv6-mål är det ofta enklast att ta bort en felaktig AAAA-post.
Vanligast är att du bara konfigurerat ett av värdnamnen på hosting-sidan (endast apex eller endast www), eller att du har konkurrerande omdirigeringsregler som studsar mellan HTTP och HTTPS eller mellan apex och www. Välj ett kanoniskt värdnamn, konfigurera båda värdnamnen och se till att det finns en enda ren omdirigeringsväg.
Ja. Väntan är ofta rätt åtgärd, men först måste DNS tydligt peka på rätt mål från flera platser. SSL-utfärdande slutförs vanligtvis inte förrän domänen konsekvent löser till det förväntade målet, och att växla DNS fram och tillbaka kan hålla processen i gång.
TTL är hur länge resolvern cacherar ett svar, så även efter att du fixat en post kan vissa nätverk fortsätta visa det gamla värdet tills TTL-fönstret löper ut. Testa från två olika nätverk (t.ex. Wi‑Fi och mobildata) och undvik att göra nya DNS-ändringar var femte minut så att du kan observera propagation cleanly.
Använd upprepbara kontroller som dig eller nslookup för att bekräfta att A/AAAA/CNAME/TXT-svaren matchar ditt förväntade mål, och testa sedan både http:// och https:// för både apex och www. Om ett nätverk visar andra DNS-svar än ett annat, behandla det som cache; om alla nätverk visar fel svar, behandla det som en konfigurationsmiss.
På Koder.ai, använd appens domäninställningsskärm som sanningskälla för förväntat DNS-mål och gör sedan DNS att matcha det exakt hos den auktoritativa leverantören. Efter att ha ändrat DNS, ge det tid att stabilisera innan du kontrollerar SSL och använd snapshots/rollback vid behov så att du snabbt kan återgå till ett känt fungerande läge.