Outbound connectivity failure to api.wordpress.org (timeout) — IP 149.202.89.199

[cbourgois]

Hello,

I'm reporting a persistent outbound connectivity failure from our server to api.wordpress.org, which is preventing WP-CLI core updates and other WordPress.org API calls from completing.

Server details:

• Public IP: 149.202.89.199 (OVH)
• Destination: api.wordpress.org — 198.143.164.251
• Affected ports: 443 (HTTPS) and 80 (HTTP) — both reproduced

Symptom:
The TCP handshake never completes. The connection hangs and eventually times out (cURL error 28: "Failed to connect... Timeout was reached").

Diagnostics performed so far:

• curl -v ​https://api.wordpress.org → hangs at "Trying 198.143.164.251:443..." until timeout
• curl -v ​http://api.wordpress.org → identical behavior on port 80
• DNS resolution is correct: api.wordpress.org resolves to 198.143.164.251
• Reproduced identically inside a Docker container AND directly on the host, bypassing all container networking
• No local firewall rule is blocking this traffic — verified both iptables and nftables rulesets (OUTPUT and FORWARD chains, Docker-related chains); outbound HTTPS/HTTP to this destination is explicitly allowed
• No outbound proxy is configured at container or system level (--noproxy '*' makes no difference)
• The exact same request succeeds without issue from a completely different network (different provider, non-OVH)
• Other destinations (e.g., 1.1.1.1) connect normally from this same server

Given that local connectivity, DNS, and firewall rules are all confirmed working, and the same request succeeds from another network, this strongly suggests the issue is occurring somewhere between our network (OVH, 149.202.89.199) and api.wordpress.org's infrastructure — possibly a rate limit or block on a specific IP or subnet.

Could you please check whether our IP (149.202.89.199) or its subnet has been flagged, rate-limited, or blocked, and help us get it resolved?

I'm happy to provide additional logs (traceroute/mtr output, full curl -v output, etc.) if useful.

Thank you for your help.

Best regards,
Christophe Bourgois
Laxmi Digital

[obenland]

Looks like it might be a matter of stale DNS on your end? Maybe check /etc/hosts (or the Windows hosts file) for a pinned api.wordpress.org entry, flush the local resolver cache, and confirm what your upstream DNS returns. It should be 66.6.42.251.

[dantist]

I am seeing a very similar connectivity issue with api.wordpress.org from multiple independent VPS servers.

At the moment, there is a consistent difference between these two WordPress.org IP addresses:

66.6.42.251:443 — reachable
66.6.42.252:443 — TCP connection times out

This has been reproduced on three different VPS servers. Two of the affected WordPress installations are already reporting:

cURL error 28: Connection timed out after 10001 milliseconds

On one affected server, WordPress HTTP API debugging showed that the failed request was attempting to connect to 66.6.42.252.

Direct tests confirm the difference:

curl -k -I --connect-timeout 10 --resolve api.wordpress.org:443:66.6.42.251 ​https://api.wordpress.org/

Result: successful connection, HTTP/2 302.

The same test against 66.6.42.252:

curl -k -I --connect-timeout 10 --resolve api.wordpress.org:443:66.6.42.252 ​https://api.wordpress.org/

Result:

curl: (28) Failed to connect to api.wordpress.org port 443 after 10002 ms: Timeout was reached

I also captured the TCP traffic with tcpdump.

For 66.6.42.252:443, the server sends repeated SYN packets but receives no response at all — no SYN/ACK and no RST:

80.87.202.101 > 66.6.42.252:443 SYN
80.87.202.101 > 66.6.42.252:443 SYN
80.87.202.101 > 66.6.42.252:443 SYN

For comparison, 66.6.42.251:443 immediately completes the normal TCP handshake:

80.87.202.101 > 66.6.42.251:443 SYN
66.6.42.251:443 > 80.87.202.101 SYN, ACK
80.87.202.101 > 66.6.42.251:443 ACK

TLS/HTTP communication then proceeds normally.

tracepath to both 66.6.42.251 and 66.6.42.252 follows essentially the same route:

Twelve99
→ Stockholm
→ Amsterdam
→ automattic-ic-369117.ip.twelve99-cust.net
→ AS2635

Both routes reach the Automattic/AS2635 network before ICMP responses stop.

Therefore, this does not appear to be a WordPress installation, PHP, cURL, TLS certificate, DNS, or application-level problem. The TCP connection itself to 66.6.42.252:443 does not complete, while 66.6.42.251:443 works normally from the same source server.

The issue is reproducible from multiple VPS servers.

Could you please confirm whether 66.6.42.252 is currently expected to serve api.wordpress.org traffic, and whether there may be filtering, routing, or return-path issues affecting connectivity to this address from some networks?

I can provide full tcpdump, tracepath, curl verbose output, and additional source IPs if useful.

[dantist]

Additional finding:

The current failure is caused by the redirect target, not by api.wordpress.org itself.

On the affected server:

api.wordpress.org resolves to 66.6.42.251 and is reachable.

It returns HTTP 302 redirecting to:

​https://developer.wordpress.org/rest-api/

developer.wordpress.org currently resolves to:

66.6.42.252

and TCP/443 to that IP times out completely.

Direct test:

curl -k -v --connect-timeout 10 ​https://developer.wordpress.org/rest-api/

attempts 66.6.42.252:443 and times out.

So WordPress Site Health fails because it follows the redirect from the reachable .251 host to developer.wordpress.org on the unreachable .252 host.

[cbourgois]

It was a DNS problem, thanks to all