Guys, my external API requests (some) are failing, this is what Claude code cli pointed out:
"
Since upgrading to 10.0.0, all workflow Send Request actions to external hosts fail with:
Workflow: Send Request action: 0 response.
GuzzleHttp\Exception\ConnectException: cURL error 7:
Failed to connect to <host> port 443 after 0 ms
Direct curl and standalone Guzzle from the same server (as the apache user) succeed against the same URL — only the
Espo HttpClient path fails.
Root cause: Commit 351a444 — "http client protection"
(https://github.com/espocrm/espocrm/c...5d69791d6453a3) (shipped in 10.0.0) added an
SSRF-protection middleware in Espo\Core\HttpClient\Client that pins CURLOPT_RESOLVE to every IP returned by
UrlCheck::getCurlResolve(). On dual-stack hosts, that includes an AAAA record. If the server has no working IPv6
route (common on AWS EC2 with default VPC / no IPv6 subnet), cURL fails immediately (0 ms) on the pinned IPv6 entry
and does not fall back to IPv4 — unlike the OS resolver, which would.
Reproduction: any external host with an AAAA record on a server without IPv6 egress. Verified with api.telegram.org
(has AAAA 2001:67c:4e8:f004::9).
Workaround: patch application/Espo/Core/Utils/Security/UrlCheck.php, method getCurlResolve(), to skip IPv6
addresses:
foreach ($ipAddresses as $ipAddress) {
if (filter_var($ipAddress, FILTER_VALIDATE_IP, FILTER_FLAG_IPV6)) {
continue;
}
$output[] = "$host:$port:$ipAddress";
}
"
Please have a look, ty
"
Since upgrading to 10.0.0, all workflow Send Request actions to external hosts fail with:
Workflow: Send Request action: 0 response.
GuzzleHttp\Exception\ConnectException: cURL error 7:
Failed to connect to <host> port 443 after 0 ms
Direct curl and standalone Guzzle from the same server (as the apache user) succeed against the same URL — only the
Espo HttpClient path fails.
Root cause: Commit 351a444 — "http client protection"
(https://github.com/espocrm/espocrm/c...5d69791d6453a3) (shipped in 10.0.0) added an
SSRF-protection middleware in Espo\Core\HttpClient\Client that pins CURLOPT_RESOLVE to every IP returned by
UrlCheck::getCurlResolve(). On dual-stack hosts, that includes an AAAA record. If the server has no working IPv6
route (common on AWS EC2 with default VPC / no IPv6 subnet), cURL fails immediately (0 ms) on the pinned IPv6 entry
and does not fall back to IPv4 — unlike the OS resolver, which would.
Reproduction: any external host with an AAAA record on a server without IPv6 egress. Verified with api.telegram.org
(has AAAA 2001:67c:4e8:f004::9).
Workaround: patch application/Espo/Core/Utils/Security/UrlCheck.php, method getCurlResolve(), to skip IPv6
addresses:
foreach ($ipAddresses as $ipAddress) {
if (filter_var($ipAddress, FILTER_VALIDATE_IP, FILTER_FLAG_IPV6)) {
continue;
}
$output[] = "$host:$port:$ipAddress";
}
"
Please have a look, ty
Comment