developer.wordpress.org (66.6.42.252) unreachable from multiple VPS networks – TCP/443 timeout

[dantist]

I am reporting a connectivity issue specifically affecting developer.wordpress.org / 66.6.42.252.

The issue is reproducible from multiple VPS servers in different hosting networks. The affected servers are hosted in Russia.

WordPress Site Health reports:

WordPress.org is unreachable
cURL error 28: Failed to connect to developer.wordpress.org port 443 after 5203 ms: Connection timed out

Current DNS

api.wordpress.org currently resolves to:

66.6.42.251

and is reachable normally.

However, requesting ​https://api.wordpress.org/ returns HTTP 302 redirecting to:

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

developer.wordpress.org resolves to 66.6.42.252.

I verified this directly against an authoritative WordPress.org nameserver:

dig @ns1.wordpress.org developer.wordpress.org A

Result:

developer.wordpress.org. 14400 IN CNAME wordpress.org.
wordpress.org. 600 IN A 66.6.42.252

The same result is currently returned by the local resolver, Cloudflare (1.1.1.1) and Google (8.8.8.8).

Therefore, this does not appear to be caused by a stale local DNS cache or a particular recursive DNS resolver.

Connectivity tests

From the same VPS, a direct connection to 66.6.42.251:443 succeeds:

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

Result: successful connection and HTTP/2 302 response.

However:

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

fails with:

curl: (28) Failed to connect to developer.wordpress.org port 443 after ~5 seconds: Connection timed out

TCP packet capture

I also captured the connection attempts using tcpdump.

For 66.6.42.252:443, the VPS repeatedly sends TCP SYN packets:

source > 66.6.42.252.443: Flags [S]
source > 66.6.42.252.443: Flags [S]
source > 66.6.42.252.443: Flags [S]

but receives no response at all — no SYN/ACK and no RST.

As a control test, 66.6.42.251:443 from the same VPS immediately completes a normal TCP handshake:

source > 66.6.42.251.443: Flags [S]
66.6.42.251.443 > source: Flags [S.]
source > 66.6.42.251.443: Flags .

HTTPS communication then proceeds normally.

This shows that the failure occurs before TLS or HTTP: the TCP connection itself to 66.6.42.252:443 cannot be established.

Routing

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.

Scope

The behavior has been reproduced on multiple VPS servers. The WordPress installations and websites themselves are otherwise functioning normally.

The same servers can establish HTTPS connections to 66.6.42.251 without problems, while 66.6.42.252:443 consistently receives no TCP response.

This does not appear to be a WordPress installation, PHP, cURL configuration, TLS certificate, plugin, or application-level issue.

It also explains the WordPress Site Health failure: the initial connection to api.wordpress.org succeeds on 66.6.42.251, but the request is redirected to developer.wordpress.org, which currently resolves to the unreachable 66.6.42.252.

Could you please check whether there is a routing, filtering, return-path, or edge-network issue affecting connectivity to 66.6.42.252:443 from these source networks or IP ranges?

I can provide the full tcpdump, tracepath, verbose curl output, and additional affected source IP addresses if required.

[fierevere]

Unfortunately this issue affects also home/business client Internet access providers, such as
SkyNet
DOMru
Megafon
Likely - many more due to "ТСПУ" used by most/all providers who are obliged to install СОРМ-equipment on their network. They dont have much access over blocking Internet access to IP/protocols, based on DPI or IP/Network. Currently they block TCP connections to port 80 and 443. There can be live ICMP ping responses.

It is not a WordPress.org or its Internet uplink/Datacenter issue. You have refer to РоскомНадзор,
blocking WordPress.org access is definitely accidental, and there is no registry record.

Мне жаль, правда...

[ivanzhuck]

The issue is solved by Roskomnadzor, the IP-address 66.6.42.252 is available now from Russian Internet networks via 443 and 80 ports. The ticket can be closed.