WordPress-fejlen "Fejl ved oprettelse af databaseforbindelse" indikerer, at din WordPress-side ikke kan oprette forbindelse til MySQL-databasen. De mest almindelige årsager er forkerte wp-config.php-credentials, en nedbrudt eller overbelastet MySQL-service, korrupte databasetabeller, utilstrækkelige hostingressourcer eller manglende brugerrettigheder. For at løse problemet bør du først verificere database-navn, brugernavn, adgangskode og serveradresse; derefter tjekke MySQL-service, tabelreparationer, ressourceforbrug og eventuelle sikkerhedsplugins.
Fejlen præsenteres typisk med en klar WordPress-advarsel, ikke bare en hvid skærm, og kan gøre både frontend og admin-panel fuldstændig utilgængelige. For e-handelsløsninger, virksomhedswebsites, medlemsportaler eller blogs med meget trafik kan selv få minutters nedetid betyde tab af ordre, formularindsendelser, annonceindtægter og brandtillid. Heldigvis er fejlen skræmmende, men kan ofte findes og løses systematisk på 10-20 minutter.
I denne Hostragons-guide får du hands-on råd, baseret på danske hosting-erfaringer og optimeret til 2026’s SEO-standarder. Vi gennemgår trin for trin: wp-config.php-tjek, MySQL-tips, serverressourceanalyse, tabelreparation, sikkerhedsrisici og praktiske forebyggende rutiner. Oplever du hyppig databaseforbindelsesfejl, skal du ikke kun fokusere på quick fixes, men også tænke i langtidsholdbare tekniske forbedringer. Valg af den rette hosting er afgørende – se også WordPress hosting pakker og Løsninger til højtydende web hosting.
Hvad er WordPress "Fejl ved oprettelse af databaseforbindelse"?
WordPress bruger ikke kun tema-filer til at generere sider; data som indlæg, sider, brugere, menuer, plugin-indstillinger, WooCommerce-ordrer og site options hentes fra en MySQL- eller MariaDB-database. Når WordPress-kernen ikke kan forbinde til databasen, vises "Fejl ved oprettelse af databaseforbindelse". Det betyder, at PHP-filerne godt kan ligge korrekt på serveren, domænet fungerer, SSL-certifikatet er aktivt – men indholdet bliver ikke genereret, fordi WordPress ikke kan nå databasen.
Fejlen kan sammenlignes med et telefonbogs-analog: WordPress prøver at slå et nummer op for at vise siden, men hvis navnet er ændret, adgangskoden er forkert, linjen er optaget eller filen er ødelagt, så kan opkaldet ikke gennemføres. Resultatet er, at sitet ikke kan vise data, selvom det tilsyneladende er online.
Fejlens konsekvenser afhænger af sidens type. På en blog vises indlæg ikke, på en WooCommerce-shop stopper kurv, betaling, lager og ordreprocesser. Medlemsportaler mister login, profil og abonnementsdata. Derfor er det vigtigt ikke at gå i panik, men følge en struktureret fejlsøgningsrække.
De mest almindelige årsager – Hurtig sammenligning
Tabellen herunder giver overblik over de hyppigste årsager til WordPress "Fejl ved oprettelse af databaseforbindelse", typiske symptomer og første skridt. Hurtig klassificering forebygger unødvendige filændringer og minimerer risiko for datatab.
| Årsag | Typisk symptom | Første tjek | Risiko |
|---|---|---|---|
| Forkerte wp-config.php oplysninger | Både site og admin er helt nede | Bekræft DB_NAME, DB_USER, DB_PASSWORD, DB_HOST | Middel |
| MySQL-service er stoppet | Fejl på alle sites på samme server | Tjek MySQL-status og alerts i hosting-panelet | Høj |
| Korrupte databasetabeller | Forskellige fejl på frontend og admin | Brug WordPress repair mode eller phpMyAdmin | Middel |
| Ressourcegrænse overskredet | Fejl under trafikspikes eller kampagner | Tjek CPU, RAM, I/O og connection-limits | Høj |
| Forkerte brugerrettigheder | Fejl efter flytning | Sikre at MySQL-brugeren har adgang til databasen | Middel |
| Sikkerheds-/firewall-blokering | Fejl efter IP-skift eller remote MySQL | Tjek IP-whitelist, firewall og plugin logs | Middel |
Før du starter: Sikker forberedelse
Panikløsninger som at slette filer, skifte tema eller deaktivere alle plugins forværrer ofte problemet. Første regel: bevare status quo mens du fejlsøger. På live sites skal du aldrig køre repair eller slette tabeller uden backup.
- Tag fil-backup: Download public_html eller WordPress-mappen.
- Tag database-backup: Brug phpMyAdmin eller hostingens backup-værktøj.
- Log seneste ændringer: Notér nye plugins, tema-opdateringer, PHP-version, flytning eller adgangskodeændringer.
- Notér fejlens tidspunkt: Det hjælper, når du analyserer MySQL-logs og ressourcegrafik.
- Skift kun én ting ad gangen: Så ser du, hvad der løser problemet.
Professionelle anbefaler at teste på et staging-miljø først. Har du ingen backup, så tjek din hostings backup-politik (daglig/ugentlig). Hos Hostragons kan du læse om backup & restore muligheder i Backup-tjenester til hosting.
Trin 1: Tjek wp-config.php-oplysninger
Nøglen til forbindelsen mellem WordPress og MySQL ligger i wp-config.php. Filen findes i WordPress-roden og rummer database-navn, brugernavn, adgangskode og serveradresse. Hvis fejlen opstod efter flytning, domæneskift, adgangskodeændring eller manuel installation, er dette første tjekpunkt.
Vigtige felter
- DB_NAME: Database-navnet skal matche præcis. Nogle paneler tilføjer et prefix.
- DB_USER: MySQL-brugernavnet skal skrives korrekt.
- DB_PASSWORD: Adgangskoden skal matche (case sensitive), inkl. specialtegn og mellemrum.
- DB_HOST: Ofte "localhost" på delt hosting, ellers separat MySQL-serveradresse.
- DB_CHARSET: Typisk "utf8mb4". Ikke hovedårsag til fejl, men forebygger tegnsætsproblemer.
Eksempel: På cPanel kan database-navnet være "konto_site_db", ikke blot "site_db". Det samme gælder brugernavne. Mangler prefix, opstår forbindelsesfejl.
Den bedste måde at verificere adgangskode er at generere en ny stærk kode i hosting-panelet og indsætte den i wp-config.php – pas på med kopiering, så der ikke sniger sig mellemrum ind, som kan bryde forbindelsen.
Trin 2: Tjek at MySQL-service kører
Hvis wp-config.php er korrekt, skal du tjekke om MySQL-service er aktiv. På delt hosting gøres det typisk fra kontrollpanelet; på VPS eller dedikeret server via SSH. Har du managed hosting, så kontakt support med fejlens tidspunkt.
På delt hosting
- Se status for services, ressourceforbrug og fejl i panelet.
- Tjek om andre WordPress-sites på samme konto virker.
- Kan du åbne phpMyAdmin? Hvis ikke, er problemet ikke kun WordPress-relateret.
- Tjek om din hosting melder om drift eller vedligeholdelse.
På VPS/server
På VPS skal du sikre, at MySQL/MariaDB er aktiv. Genstart kan hjælpe midlertidigt, men årsagen kan være RAM-mangel, diskplads, korrupte tabeller eller tunge queries. Fx kan MySQL lukke ned, hvis PHP-FPM, webserver og MySQL konkurrerer om RAM på en server med kun 2 GB.
Diskplads er ofte en joker: Hvis MySQL ikke kan skrive temp-filer eller logs, opstår fejl. Over 90% diskbrug bør give alarm. Løsningen kan være log rotation, sletning af unødvendige backups, databaseoptimering eller opgradering af ressourcer. For skalérbar VPS, se Hostragons VPS serverløsninger.
Trin 3: Tjek databasebrugerens rettigheder
Det er ikke nok, at brugeren eksisterer – den skal have de rette rettigheder til den aktuelle database. Efter flytning glemmes det ofte at tildele brugeren adgang. Det kan give forbindelses- eller permissionsfejl.
Tilføj brugeren til databasen i hosting-panelets "MySQL Databaser" og giv de nødvendige rettigheder: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP. Det er god praksis at lave separate brugere/databaser for hver site – så kompromitteres kun én site ved sikkerhedsbrud.
For bureauer og teams: Dokumentér projekt-/database-/bruger-navn, oprettelsesdato og ansvarlig i en password manager. Det sparer tid ved flytning og fejlsøgning.
Trin 4: Reparer databasetabeller
Nogle gange er credentials og service okay, men fejlen fortsætter – her er tabellerne måske korrupte. Det kan ske ved pludselig servernedlukning, mislykket opdatering, diskproblemer eller mange samtidige writes.
WordPress "repair mode"
WordPress har indbygget repair-funktion. Tilføj midlertidigt WP_ALLOW_REPAIR i wp-config.php for at åbne repair-siden. Fjern linjen igen efter reparation – repair-siden kan ellers tilgås uden login og udgør en sikkerhedsrisiko.
phpMyAdmin reparation og optimering
I phpMyAdmin kan du vælge tabeller og køre "repair table" og "optimize table". På store WooCommerce-sites kan det midlertidigt gøre sitet langsomt. Tag altid backup først, især af tabeller som wp_postmeta, wp_options og order-tables.
Eksempel: En WooCommerce-shop med 50.000 produkter kan have millionvis af poster i wp_postmeta. Optimering på delt hosting kan ramme ressourcelimit. Kør derfor reparation på lavtrafik-tidspunkter, test gerne på staging først, og samarbejd med hosting-support.
Trin 5: Vurder plugins, temaer og seneste opdateringer
Selvom fejlen ikke typisk skyldes et plugin, kan nogle plugins belaste databasen og overskride forbindelsesgrænser. Særligt sikkerheds-scannere, statistik-plugins, backup-værktøjer, automatiske imports og dårligt kodede page builders kan lave tunge queries.
Hvis fejlen gentages på bestemte tidspunkter, tjek cron jobs. Fx kan backup, produkt-synkronisering og security scan på samme tid give mange samtidige MySQL-forbindelser. Spred opgaverne ud over flere tidspunkter for hurtig aflastning.
- Deaktiver nye plugins midlertidigt.
- Flyt backup/scanning til lavtrafik.
- Brug eksterne analyseværktøjer i stedet for plugins med konstant database-write.
- Tjek scheduled tasks for kurv, session og actions på WooCommerce-sites.
- Opdater temaer/plugins på test først, ikke live.
Trin 6: Analyser hostingressourcer

Mange databaseforbindelsesfejl skyldes ikke forkert opsætning, men mangel på ressourcer. På delt hosting har du grænser for CPU, RAM, I/O, entry process og MySQL connections. Trafikspikes, bot-angreb, kampagner eller tunge queries kan gøre, at WordPress ikke når databasen.
Undgå at stirre blindt på trafik-tallet: 100 ægte brugere kan være mindre belastende end 10.000 bot-requests. En godt cachet side laver måske én query, mens en WooCommerce-kategori uden cache kan lave dusinvis. Vurder derfor både request count, query time, PHP processer og database response.
Hvornår skal du opgradere hosting?
- Fejlen opstår kun ved peak-tider.
- Ressourcegrafik når ofte 80-100%.
- Du har dynamisk site (WooCommerce, LMS, medlemskab).
- MySQL laver stadig langsomme queries trods cache.
- Du hoster mange WordPress-sites på samme konto.
Har du disse symptomer, er det tid til mere kraftfuld WordPress hosting, cloud-server eller managed VPS. Saml domæne, hosting og SSL i ét økosystem for lettere drift. Se Domæneregistrering, SSL certifikat og Virksomheds hosting løsninger.
Praktiske MySQL-tips for ydeevne
For at undgå gentagne fejl kræver MySQL løbende vedligehold. WordPress-databasen vokser – gamle revisioner, spam-kommentarer, temporære options, cron-rester og plugin-logs kan sløve queries. Her er fem tips, som både mindsker forbindelsesfejl og øger site-hastighed:
1. Hold wp_options-tabellen ren
wp_options er en nøgle-tabel. Rækker med autoload=yes loades i RAM ved hver sidevisning. Ubrugte autoload-data på fx 5-10 MB trækker loadtider op. Tag backup før du sletter, og identificér hvilket plugin data tilhører.
2. Begræns revisioner
På blogs med mange forfattere oprettes revisioner for hver ændring. 500 indlæg med 20 revisioner hver giver tusindvis af ekstra rækker. Begræns revisioner for at holde wp_posts og wp_postmeta manageable.
3. Brug persistent object cache
Redis eller Memcached kan cache ofte brugte query-resultater, så MySQL ikke belastes. På medlems- og WooCommerce-sites er full page cache ikke nok, da mange sider er bruger-specifikke. Her kan object cache gøre en stor forskel.
4. Overvåg langsomme queries
På VPS/server, aktivér slow query log for at finde tunge queries (>2 sek.). Det gør det let at spotte problematiske plugins eller manglende indexes. På delt hosting er det ofte begrænset – brug i stedet performance-plugins og hosting-support.
5. Begræns bot-trafik
Botter kan spamme dynamiske WordPress-sider og tømme MySQL-forbindelser. Brug firewall, rate limiting, CDN, optimer robots.txt og beskyt login-siden. Særligt wp-login.php og xmlrpc.php skal holdes under kontrol.
Sikkerhed: Kan fejlen skyldes angreb?
Ikke alle forbindelsesfejl skyldes hacking, men brute force, bot-scanning, SQL-injection eller malware-plugins kan belaste MySQL. Pludselige spikes, ukendte admin-brugere, mistænkelige filer og trafik fra usædvanlige kilder bør give anledning til sikkerhedstjek.
Forebyggelse: Hold WordPress, tema og plugins opdateret. Slet ubrugte plugins. Brug stærke passwords og 2FA. Giv kun nødvendige database-rettigheder. Brug ikke samme MySQL-bruger til flere sites. SSL løser ikke forbindelsesfejl, men sikrer dataoverførsel. Se hvad er SSL certifikat og hvordan man installerer det for mere info.
Hvorfor ses denne fejl ofte efter site-flytning?
WordPress-flytning er klassisk anledning til databaseforbindelsesfejl. Filerne kan være flyttet korrekt, men database-import kan være mangelfuld, brugerrettigheder glemt, eller wp-config.php kan have gamle serverdata. Når DNS propagere, kan nogle besøgende nå den gamle server og andre den nye – det gør fejlsøgning svær.
Flytningstjekliste: Nyt databasename, nyt brugernavn, opdateret adgangskode, korrekt DB_HOST, phpMyAdmin-adgang, tabelprefix, site-URL, PHP-version og filrettigheder. Tjek at DNS peger på korrekt IP. For domæneadministration, se Domæneforespørgsel og domænestyring.
Permanent forebyggelse – Tjekliste
En engangsløsning er ikke nok. Undgå gentagne fejl ved at implementere disse rutiner månedligt – eller ugentligt på store sites:
- Daglig backup og test af restore.
- Opdater WordPress, tema og plugins kontrolleret.
- Overvåg database-størrelse, især wp_options og wp_postmeta.
- Tjek ressourcegrafik ugentligt.
- Begræns bot, brute force og xmlrpc requests.
- Hold PHP og MySQL opdateret til understøttet version.
- Test store ændringer på staging før live.
- Opgrader hosting før kampagner med forventet trafikstigning.
Som tommelfingerregel bør du planlægge optimering eller upgrade, hvis du ofte rammer 80% af dine ressourcelimits. Databaseforbindelsesfejl er ofte sidste advarsel – se også symptomer som langsomme sider, timeouts og resource alerts i admin.
Hvornår skal du søge professionel hjælp?
Simple wp-config.php-rettelser kan de fleste klare selv, men store databaser, e-handels-sites, trafik-tunge projekter eller VPS kræver ofte ekspertise. Særligt tabelreparation, serverkonfiguration, RAM/MySQL-tuning kræver erfaring.
Søg assistance hvis: du ikke har backup, databasen er meget stor, fejlen gentages ofte, WooCommerce med betaling er påvirket, du ikke kan tolke serverlogs, eller MySQL crasher gentagne gange. Korrekt hjælp sikrer ikke kun genopretning, men forebygger fremtidige nedbrud.
Kort opsummering og blød CTA
WordPress "Fejl ved oprettelse af databaseforbindelse" er kritisk, men kan som regel løses. Det bedste er at tjekke wp-config.php, MySQL-status, brugerrettigheder, tabelreparation og hostingressourcer i rækkefølge. For varig løsning: brug backup, databaseoptimering, sikkerhedstiltag og hosting tilpasset din trafik.
Hvis din side ofte får databasefejl, er langsom ved trafikpeak eller ressourcer ikke slår til, kan Hostragons’ WordPress-hosting, VPS, domæne og SSL-løsninger give dig en mere robust platform. Analysér dit behov før køb – det sikrer sund drift på lang sigt.
Ofte stillede spørgsmål
Hvorfor får jeg "Fejl ved oprettelse af databaseforbindelse" i WordPress?
Typisk skyldes det, at WordPress ikke kan forbinde til MySQL-databasen. Hyppigste årsager: fejl i wp-config.php, forkert adgangskode, stoppet MySQL-service, korrupte tabeller, manglende hostingressourcer eller manglende brugerrettigheder.
Hvilke oplysninger skal jeg tjekke i wp-config.php?
DB_NAME, DB_USER, DB_PASSWORD og DB_HOST. Vær opmærksom på prefix i database- og brugernavn. Adgangskoder skal matche præcis, inkl. specialtegn og uden ekstra mellemrum.
Betyder fejlen, at mine data er slettet?
Nej, data er som regel intakte – WordPress kan bare ikke nå databasen. Tag altid backup før reparation, optimering eller ændring af bruger.
Er det sikkert at reparere MySQL-tabeller?
Ja, hvis du har backup. Brug WordPress repair mode eller phpMyAdmin. På store WooCommerce eller trafik-tunge sites bør du planlægge reparation til lavtrafik og teste på staging.
Hvordan undgår jeg, at fejlen opstår igen?
Tag backup regelmæssigt, hold WordPress og plugins opdateret, overvåg store tabeller (wp_options, wp_postmeta), begræns bottrafik, følg ressourcegrafik og brug hosting, der matcher din trafik.