Ha egy bővítményfrissítés így áll le: „Download failed. cURL error 28: Connection timed out after 10001 milliseconds”, vagy egy licencellenőrzés, fizetési modul a „cURL error 60: SSL certificate problem: unable to get local issuer certificate” hibát naplózza, a WordPress egy másik szervert próbált elérni, és nem sikerült. Mindkét üzenet a cURL-től származik, attól a programkönyvtártól, amellyel a PHP webes kéréseket küld.

• A 28-as hiba mindig időtúllépés: valahol az úton valami nem válaszolt, amíg az időkorlát le nem járt.
• A 60-as hiba azt jelenti, hogy a kapcsolat létrejött, de a távoli szerver tanúsítványát nem sikerült ellenőrizni.

Az üzenet további szövegéből kiderül, hol akadt el a kérés, és az is, kinek a dolga a javítás: az Öné, a mi ügyfélszolgálatunké vagy a távoli szolgáltatóé.

1. Jegyezze fel a pontos hibát

A hiba a Bővítmények vagy a Vezérlőpult › Frissítések oldalon, a bővítmény saját naplójában, vagy az Eszközök › Webhely Egészség oldalon jelenik meg. Ott például így: „Nem sikerült elérni a WordPress.org-ot”, alatta a cURL-hibával és az IP-címmel. Jegyezze fel a hiba számát, a szám utáni szöveget, és a címet, amelyet a webhely el akart érni.

2. Ismételje meg a kérést a WordPressből

A cPanel Terminal (Speciális csoport) vagy SSH ugyanazt a PHP-t és WordPresst használja, mint a webhely. A webhely mappájában:

cd ~/public_html
wp eval '$r = wp_remote_get( "https://api.wordpress.org/core/version-check/1.7/" ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_response_code( $r ), PHP_EOL;'

Rendben lévő webhelyen a válasz 200. A WordPress.org helyett beírhatja a bővítmény licencszerverének vagy a fizetési szolgáltatónak a címét is. Bármilyen állapotkód, akár 401 vagy 404 is azt jelenti, hogy a hálózati út működik, a távoli szerver válaszolt. A WP-CLI alapjait a WP-CLI használatáról szóló cikk írja le.

3. Ismételje meg curl-lel, időméréssel

Ez a WordPresstől függetlenül fut, így elválasztja a WordPress-beállítást a hálózattól:

curl -sS -o /dev/null --max-time 10 -w 'dns=%{time_namelookup} kapcsolat=%{time_connect} tls=%{time_appconnect} elso_bajt=%{time_starttransfer} ip=%{remote_ip} kod=%{http_code}\n' https://api.wordpress.org/core/version-check/1.7/

A teszt-tárhelyünkön (aWh cPanel szerver):

dns=0.000184 kapcsolat=0.082131 tls=0.169085 elso_bajt=0.252814 ip=2620:109:b00a::4206:2afb kod=200

Minden érték a kezdettől eltelt másodperc. Hiba esetén a curl egy hibasort is kiír; a táblázat megmutatja, hol akadt el:

A curl ezt írja	Hol akadt el	Ki javítja
curl: (28) Resolving timed out vagy curl: (6) Could not resolve host	névfeloldás (DNS)	aWh ügyfélszolgálat
curl: (7) Failed to connect … Connection refused (azonnal)	a kimenő port tiltva van	aWh ügyfélszolgálat
curl: (28) Connection timed out	tűzfal vagy hálózati útvonal	aWh ügyfélszolgálat
curl: (28) Operation timed out … with 0 bytes received	a távoli szerver nem válaszol időben	a távoli szolgáltató
curl: (60) SSL certificate problem: …	tanúsítvány-ellenőrzés	lásd az 5. lépést

4. Ha a curl működik, de a WordPress nem

Két wp-config.php állandó letilthatja a kimenő kéréseket még azelőtt, hogy elindulnának:

wp config get WP_HTTP_BLOCK_EXTERNAL
wp config get WP_ACCESSIBLE_HOSTS
wp config get WP_PROXY_HOST

A normális válasz mindháromra az, hogy az állandó nincs megadva. Ha a WP_HTTP_BLOCK_EXTERNAL be van kapcsolva, a WordPress csak a saját webhelyét és a WP_ACCESSIBLE_HOSTS listában szereplő címeket érheti el; az üzenet ilyenkor „User has blocked requests through HTTP”. Vegye fel a szükséges címeket vesszővel elválasztva (a * helyettesítő karakter):

wp config set WP_ACCESSIBLE_HOSTS 'api.wordpress.org,*.wordpress.org,api.szolgaltato.hu'

Egy megszűnt proxyszerver (WP_PROXY_HOST) ugyanilyen időtúllépést okoz; ha nem használ proxyt, törölje: wp config delete WP_PROXY_HOST.

5. A 60-as hiba: tanúsítvány

A „SSL certificate problem:” utáni szöveg megmondja az okot:

• „unable to get local issuer certificate”: a tanúsítványtár nem ismeri a kibocsátót, vagy a távoli szerver nem küldi el a köztes tanúsítványt.
• „certificate has expired”: a távoli szerver tanúsítványa lejárt, ezt a szolgáltatónak kell megújítania.
• „self-signed certificate in certificate chain”: a kérés útjában egy eszköz bontja a titkosítást (például egy szűrő proxy).

A WordPress a saját kéréseihez a saját tanúsítványtárát használja (wp-includes/certificates/ca-bundle.crt), amely a WordPress frissítésével frissül. Ha régi a WordPress, előbb frissítse. Ezután nézze meg, mit küld a távoli szerver:

echo | openssl s_client -connect api.szolgaltato.hu:443 -servername api.szolgaltato.hu -showcerts 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'

Egy helyes lánc legalább két elemből áll (a szerver tanúsítványa és a köztes tanúsítvány). Ha csak a 0 sor látszik, a távoli szerverről hiányzik a köztes tanúsítvány; ezt a szolgáltatónak kell javítania, írjon nekik a parancs kimenetével. A köztes tanúsítványokról külön cikk szól.

6. A kimenő portok

A cPanel tárhely szervereinken a webhelyek a szabványos portokon (HTTP 80, HTTPS 443) szabadon érnek el más szervereket; a teszt-tárhelyünkön a WordPress.org IPv6-on, gond nélkül válaszolt. Ha egy szolgáltatás nem szabványos portot használ (például https://api.szolgaltato.hu:8443), a kapcsolatot a tűzfal azonnal elutasítja (cURL error 7), vagy időtúllépéssel elakad (cURL error 28). Ilyenkor írjon ügyfélszolgálatunknak: küldje el a 3. lépés kimenetét és a szolgáltatás címét a porttal együtt, és megnézzük, engedélyezhető-e.

Szintén nekünk szóljon, ha a névfeloldás akad el, vagy ha a hiba csak időnként jelentkezik (például minden tizedik kérésnél). A 3. lépés parancsát futtassa le tízszer egymás után, és küldje el, melyik érték ugrik meg.

7. Lassú távoli szolgáltatás: csak arra emelje az időkorlátot

Ha a kapcsolat és a tls érték gyors, mégis „Operation timed out … with 0 bytes received” a válasz, a távoli szerver lassú. Előbb nézze meg a szolgáltató állapotoldalát. Ha a lassúság tartós, egyetlen címre emelheti az időkorlátot egy must-use bővítménnyel (wp-content/mu-plugins/szolgaltato-idokorlat.php):

<?php
/**
 * Plugin Name: Hosszabb időkorlát egy lassú API-hoz
 */
add_filter( 'http_request_args', function ( $args, $url ) {
    if ( 'api.szolgaltato.hu' === wp_parse_url( $url, PHP_URL_HOST ) ) {
        $args['timeout'] = 15;
    }
    return $args;
}, 10, 2 );

Maradjon 15 másodperc alatt: amíg egy kérés vár, egy PHP-folyamatot foglal, és ha egy oldal is erre a kérésre vár, a látogató is vele vár.

Ellenőrzés

Ismételje meg a 2. lépést minden címre, amely hibát adott; mindegyiknek állapotkódot kell visszaadnia, nem cURL-hibát. Ezután a Webhely Egészség saját tesztje:

wp eval 'require_once ABSPATH . "wp-admin/includes/class-wp-site-health.php"; $r = WP_Site_Health::get_instance()->get_test_dotorg_communication(); echo $r["label"], PHP_EOL;'

A várt válasz: „Sikerült kapcsolatba lépni a WordPress.org-gal”. Végül próbálja újra a frissítést a Vezérlőpult › Frissítések oldalon.

Amit ne tegyen

• Ne kapcsolja ki a tanúsítvány-ellenőrzést (sslverify = false, vagy a https_ssl_verify szűrő). A hibaüzenet eltűnik, de bárki, aki a kapcsolat útjába kerül, a frissítési szerver vagy a fizetési rendszer nevében válaszolhat.
• Ne emelje az összes időkorlátot 60 másodpercre. Egy hibás névfeloldást vagy tiltott portot ez nem javít meg, viszont minden oldal, amely külső szolgáltatást hív, ennyivel lassabb lehet.