U wilt een plugin bijwerken en krijgt te zien: “Er is een fout opgetreden: cURL error 28: Operation timed out after 10000 milliseconds.” Of uw betaalplugin meldt “cURL error 60: SSL certificate problem”. Of het scherm Sitegezondheid zegt dat de REST API niet bereikbaar is, met opnieuw een cURL-fout in de toelichting. Het woord cURL zegt de meeste ondernemers niets, en de melding geeft weinig aanknopingspunten.

Toch is een cURL error in WordPress meestal goed te duiden. In dit artikel leggen we uit wat cURL is, welke foutcodes u het vaakst tegenkomt, waar ze vandaan komen en in welke volgorde u de oorzaak opspoort.

Wat cURL doet in WordPress

cURL is een programma op de server dat verbindingen legt met andere servers. WordPress gebruikt het overal waar uw site met de buitenwereld praat: updates ophalen bij wordpress.org, een betaling doorgeven aan Mollie, een e-mail versturen via een SMTP-dienst, een licentie controleren bij de maker van een premium plugin, of een verzoek doen aan zichzelf voor geplande taken.

Gaat zo’n verbinding mis, dan geeft cURL een foutcode terug en WordPress toont die aan u. De code vertelt in welke fase het misging. Dat is nuttig, want een time-out is iets heel anders dan een certificaatprobleem, en ze hebben dus ook een andere oplossing.

De cURL error in WordPress die u het vaakst ziet: code 28

“Operation timed out” betekent dat uw server een verbinding probeerde te maken, maar dat de andere kant niet op tijd antwoordde. WordPress wacht standaard vijf tot tien seconden en geeft het dan op.

De oorzaken lopen uiteen:

  • De andere server is traag of tijdelijk niet bereikbaar. Bij een update van wordpress.org of een licentiecheck komt dat voor. Probeer het een kwartier later opnieuw voordat u iets aanpast.
  • Uw eigen server is overbelast. Als de melding bij het REST API- of loopback-onderzoek in Sitegezondheid staat, kan de server zichzelf niet op tijd antwoorden. Dat wijst op te weinig capaciteit of op een plugin die bij elke aanroep zwaar werk doet.
  • Een firewall blokkeert uitgaand verkeer. Sommige hostingpartijen beperken welke verbindingen een site naar buiten mag leggen. Dan blijft het verzoek hangen tot de tijd om is.
  • Een beveiligingsplugin houdt het verzoek tegen. Vooral bij loopbacks: de plugin ziet een verzoek van de eigen server en vertrouwt het niet.

Deze code is bijna altijd een hosting- of serverkwestie. Als hij structureel terugkomt, is uw hostingpartij de eerste die u belt.

Code 60: het certificaat wordt niet vertrouwd

“SSL certificate problem: unable to get local issuer certificate” betekent dat uw server het certificaat van de andere partij niet kan controleren. De verbinding wordt dan uit voorzorg geweigerd. Dit is geen probleem met het certificaat van uw eigen site, maar met de lijst van vertrouwde uitgevers op uw server.

Die lijst is een bestand dat de hostingpartij beheert. Als hij verouderd is, worden nieuwere certificaten niet herkend. Een bekend moment was het verlopen van een oud rootcertificaat van Let’s Encrypt in 2021, waardoor op oudere servers plotseling allerlei koppelingen uitvielen. Ook een verkeerd ingestelde datum op de server kan deze fout geven, omdat een certificaat dan “nog niet geldig” of “verlopen” lijkt.

U kunt dit niet vanuit WordPress oplossen. Vraag uw hostingpartij om het CA-bundelbestand bij te werken. Kom nooit in de verleiding om certificaatcontrole uit te zetten met een codesnippet die u op een forum vindt; daarmee zet u de deur open voor iemand die zich voordoet als uw betaalprovider.

Code 6 en 7: de andere server is niet te vinden of weigert

“Could not resolve host” (code 6) betekent dat de domeinnaam van de andere partij niet kon worden vertaald naar een IP-adres. Meestal is de DNS-server van uw hostingpartij tijdelijk gestoord, of is de domeinnaam in een plugin-instelling verkeerd getypt. Bij een loopback naar uw eigen site kan het ook betekenen dat de server zijn eigen domein niet kent, wat na een verhuizing nog wel eens gebeurt.

“Failed to connect” (code 7) betekent dat de domeinnaam wel bekend was, maar de verbinding werd geweigerd. Denk aan een geblokkeerde poort, een uitgaande firewall of een dienst die gewoon uit de lucht is. Ook hier: eerst even wachten, dan de hostingpartij.

Minder vaak, maar wel lastig: codes 35, 51 en 56

Code 35 wijst op een mislukte SSL-handshake, vaak omdat uw server een verouderde versie van OpenSSL of TLS gebruikt die de andere partij niet meer accepteert. Betaalproviders en verzenddiensten scherpen hun eisen regelmatig aan; een server die al jaren niet is bijgewerkt valt dan opeens buiten de boot. Code 51 betekent dat de naam op het certificaat niet klopt met het domein. Code 56 is een verbinding die halverwege werd verbroken, meestal een netwerkstoring of een te lang wachtende server.

Alle drie zijn serverkwesties. Een verouderde PHP- of OpenSSL-versie is hier de rode draad, en dat is dan ook waar u het gesprek met uw hostingpartij begint.

Zo gaat u te werk

  1. Noteer de volledige melding, inclusief code en de URL die wordt genoemd. Die URL vertelt of het om een externe dienst of om uw eigen site gaat.
  2. Wacht een kwartier en probeer opnieuw. Een verrassend groot deel van de meldingen is een tijdelijke storing bij de andere partij.
  3. Open Gereedschap, Sitegezondheid. Staan daar meldingen over loopback of REST API, dan is het probleem uw eigen server. Staan die er niet, dan gaat het om een specifieke externe dienst.
  4. Schakel tijdelijk de beveiligingsplugin uit (of zet hem in leermodus) en test opnieuw. Verdwijnt de fout, dan moet u in de plugin een uitzondering maken voor het eigen IP-adres of de betreffende dienst.
  5. Controleer de PHP-versie en de serverdatum op het tabblad Info in Sitegezondheid.
  6. Neem contact op met uw hostingpartij met de foutcode, de URL en de tijd. Vraag specifiek naar uitgaande verbindingen, het CA-bundelbestand en de OpenSSL-versie. Zonder die details krijgt u vaak het antwoord “bij ons werkt alles”.

Praktijkvoorbeeld: een installatiebedrijf in Apeldoorn

Een installatiebedrijf uit Apeldoorn kon opeens geen plugins meer bijwerken. Elke poging eindigde in “cURL error 28”. De eigenaar had al een andere update-plugin geprobeerd en de site twee keer opnieuw laten laden. Bij de controle bleek Sitegezondheid ook een mislukt loopback-verzoek te melden. De server had het dus vooral moeilijk met zichzelf.

De oorzaak was een statistiekenplugin die bij elk verzoek naar een externe dienst belde om bezoekers te verrijken met locatiegegevens. Die dienst was traag geworden, en omdat de plugin op het verzoek wachtte, liep alles vast, ook de loopback. Na het uitschakelen van die functie werkten de updates weer binnen een minuut. Geen hostingprobleem dus, al leek het er sterk op. Dat is de reden waarom wij bij dit soort meldingen altijd eerst kijken welke plugin het verzoek eigenlijk doet. Wie dit liever niet zelf uitzoekt, kan zo'n foutmelding laten oplossen tegen een vast tarief.

Voorkomen

Houd de PHP-versie actueel, kies hosting die uitgaande verbindingen niet zonder overleg beperkt en beperk het aantal plugins dat bij elk verzoek naar buiten belt. Controleer daarnaast na elke verhuizing of de server zijn eigen domein kent; problemen na een migratie hebben vaak precies deze vorm, zoals we bespreken in de controlelijst na een verhuizing. Wie een cURL-fout ziet, hoeft niet in paniek te raken. Noteer de code, kijk in Sitegezondheid en begin bij de server. In negen van de tien gevallen zit daar het antwoord.