Issue
WordPress core, plugin, and theme updates started failing for all of my development sites with the same Error 6 (Could not resolve host). I can use both CLI Curl and Curl in PHP outside of WordPress in the same environment on the same URLs with no errors.
I'd love any ideas or leads.
Curl, httpd, PHP, MariaDB, and others were installed using Homebrew.
I've tried
- reinstalling Curl and httpd
- I've tried using PHP 8.2, 8.1, 7.4
- a fresh WordPress install and many existing installs
- using a mu-plugin and editing the php in WordPress includes files to try changing the curl options
...and get the same error result.
I couldn't figure out how to see what CURLOPTS were set at the time of or soon after calling curl_exec(). I suspect an option that WordPress sets and wanted to recreate it in a php script outside of WordPress.
example of a mu-plugin changing a curl option in WordPress
<?php
add_action( 'http_api_curl', function( $curl_handle ) {
curl_setopt( $curl_handle, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );
});
about my environment
- macOS Sonoma 14.2.1 (now, but this started with Ventura)
- M1 Max
- WordPress 6.4.2 (but also same problem with at least 6.3 and 5.9.8)
> which curl
curl: aliased to /opt/homebrew/opt/curl/bin/curl
> curl -V
curl 8.5.0 (aarch64-apple-darwin23.0.0) libcurl/8.5.0 (SecureTransport) OpenSSL/3.2.0 zlib/1.2.12 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libssh2/1.11.0 nghttp2/1.58.0 librtmp/2.3 OpenLDAP/2.6.6
Release-Date: 2023-12-06
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
> php -i | grep "SSL Version"
SSL Version => (SecureTransport) OpenSSL/3.2.0
PHP Version 8.1.27
Curl | |
---|---|
cURL support | enabled |
cURL Information | 8.5.0 |
Age | 10 |
Features | |
AsynchDNS | Yes |
CharConv | No |
Debug | No |
GSS-Negotiate | No |
IDN | Yes |
IPv6 | Yes |
krb4 | No |
Largefile | Yes |
libz | Yes |
NTLM | Yes |
NTLMWB | No |
SPNEGO | Yes |
SSL | Yes |
SSPI | No |
TLS-SRP | Yes |
HTTP2 | Yes |
GSSAPI | Yes |
KERBEROS5 | Yes |
UNIX_SOCKETS | Yes |
PSL | No |
HTTPS_PROXY | Yes |
MULTI_SSL | Yes |
BROTLI | Yes |
Protocols | dict, file, ftp, ftps, gopher, gophers, http, https, imap, imaps, ldap, ldaps, mqtt, pop3, pop3s, rtmp, rtmpe, rtmps, rtmpt, rtmpte, rtmpts, rtsp, scp, sftp, smb, smbs, smtp, smtps, telnet, tftp |
Host | aarch64-apple-darwin23.0.0 |
SSL Version | (SecureTransport) OpenSSL/3.2.0 |
ZLib Version | 1.2.12 |
libSSH Version | libssh2/1.11.0 |
Thanks!
Solution
tldr;
- Too many virtual hosts with their own logs broke it.
- Using a common log fixed it.
epilogue
I think I figured out the problem though I can't see the connection to why the only visible symptom was this particular way of breaking curl.
I have many virtual hosts and each one has its own access_log and error_log. I started using the troubleshooting strategy of just trying random stuff and disabling all but two sites got those two sites to work normally. I then searched for things like "too many virtual hosts" and learned about file limits and that having too many separate logs can cause problems. I rewrote my virtual host definitions to use a common log and restored all of them. After that, curl and WordPress updates started working for all of my local sites.
Answered By - Aaron Surrain Answer Checked By - Pedro (WPSolving Volunteer)