mcp.dataverse.org: TLS handshake never completes (tested 8 EU exits)

[EduardsSk]

Summary

mcp.dataverse.org (the public managed MCP server documented at https://guides.dataverse.org/en/6.7.1/ai/) appears to be globally unreachable as of 2026-05-03 ~10:00 UTC. TCP connections complete to port 443, but the TLS handshake never progresses — the server accepts the connection and then never sends ServerHello. From a few endpoints, clients see SSL_UNEXPECTED_EOF_WHILE_READING mid-handshake; from most, the connection simply hangs until client-side timeout.

I tested from 8 distinct source IPs across 7 countries (NordVPN exits + direct ISP) and got identical results, so this is server-side, not a regional / ISP / cloud-provider block.

Reproduction

$ curl -X POST "https://mcp.dataverse.org/tools/get_croissant_record" \
    -H "Content-Type: application/json" \
    -d '{"doi":"doi:10.7910/DVN/WGCRY7"}'
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

$ curl -v --max-time 10 https://mcp.dataverse.org/sse
*   Trying 157.230.86.15:443...
* Connected to mcp.dataverse.org (157.230.86.15) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
[hangs — no ServerHello received within 10s, then timeout]

$ openssl s_client -connect mcp.dataverse.org:443 -servername mcp.dataverse.org < /dev/null
[no output — connection accepted but TLS handshake never starts]

Test matrix — 8 source IPs, 7 countries

All probes target https://mcp.dataverse.org/sse (also tested /tools/get_croissant_record, same result).

Exit	Source IP	TCP→157.230.86.15:443	TLS+HTTP	Notes
Direct ISP (Latvia)	62.205.198.62	TCP timeout	curl 28 (timeout)	baseline
NordVPN Latvia #71	(LV)	TCP open	curl 28 (timeout)	TLS hangs
NordVPN Estonia #66	85.190.239.65	TCP open	curl 28 (timeout)	TLS hangs
NordVPN Lithuania #10	185.65.50.172	TCP open	curl 28 (timeout)	TLS hangs
NordVPN Germany #1094	5.180.61.56	TCP open	curl 28 (timeout)	TLS hangs
NordVPN Netherlands #822	86.104.23.92	TCP open	curl 28 (timeout)	TLS hangs
NordVPN France #679	45.84.136.227	TCP open	curl 28 (timeout)	TLS hangs
NordVPN UK #1886	91.196.221.192	TCP open	curl 28 (timeout)	TLS hangs

Cross-checks from the same clients (proves outbound HTTPS works in general):

Target	Result
https://api.github.com/zen	HTTP 200 in 121 ms
https://mcp.context7.com/mcp (another public MCP server)	HTTP 405 in 517 ms
Other DigitalOcean-hosted endpoints	reachable

So the failure is specific to mcp.dataverse.org — not the local network, not NordVPN, not DigitalOcean as a whole, not MCP-over-SSE in general.

What seems to be happening

• TCP layer is healthy: server completes the 3-way handshake.
• Application/TLS layer is broken: server accepts the socket but never sends ServerHello, OR closes the socket mid-handshake (SSL_UNEXPECTED_EOF_WHILE_READING).
• This pattern is consistent with: TLS-terminating reverse proxy crashed/hung, or app behind it crashed and the proxy holds the socket open without responding.

Impact

The README and guides.dataverse.org both recommend the public server for getting started. Users following those instructions currently hit a silent timeout with no clear remediation pointer — the failure is opaque (looks like a network problem, but isn't). Several MCP clients (Claude Desktop via npx mcp-remote, Cursor) just show "Failed to connect" with no further detail.

Suggested next steps for maintainers

1. Confirm/restart the service on the host at 157.230.86.15.
2. Check TLS termination layer (nginx/Traefik/Caddy/etc.) for stuck workers.
3. Add a health check / status badge so users can distinguish outage from misconfiguration.
4. Consider documenting the local-Docker fallback (docker compose up -d from the repo) more prominently, given how heavy the dependencies are when self-hosting.

Happy to provide additional diagnostics (full curl -v, tcpdump, openssl handshake bytes) if useful.

---

Tested with: curl 8.x on Arch Linux + Ubuntu 24.04, Node 22.x via mcp-remote, openssl 3.x.

[4tikhonov]

Changed to different instance, can you test again?

[4tikhonov]

curl -X POST "https://mcp.dataverse.org/tools/get_croissant_record" -H "Content-Type: application/json" -d '{"doi":"doi:10.7910/DVN/WGCRY7"}'|jq .|more
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 211k 100 211k 100 32 58703 8 0:00:04 0:00:03 0:00:01 58711
{
"@context": {
"@language": "en",
"@vocab": "https://schema.org/",
"citeAs": "cr:citeAs",
"column": "cr:column",
"conformsTo": "dct:conformsTo",
"cr": "http://mlcommons.org/croissant/",
"rai": "http://mlcommons.org/croissant/RAI/",
"data": {
"@id": "cr:data",
"@type": "@JSON"
},

[EduardsSk]

Confirmed working from my baseline ISP — thanks for the fast turnaround.

Retest from same client setup as before:

Exit	Result
Direct ISP (Latvia, 62.205.198.62)	HTTP 200, 217 KB Croissant payload in 4.4 s ✓
NordVPN Latvia (185.214.96.28)	Started transferring (38 KB of 217 KB), then timed out at 15 s
NordVPN Germany (94.156.151.117)	HTTP 000, 0 B (still hanging)
NordVPN UK (194.88.100.149)	HTTP 000, 0 B (still hanging)

So the new backend works for direct/normal-routed clients, but VPN exits (at least these NordVPN ones) still hit the issue intermittently. Could be the NordVPN egress IPs are flagged somewhere upstream, or the new instance still has worker/concurrency limits the previous one had. Not blocking for my use case — happy to close this on confirmation, or leave open if the VPN-exit data is useful signal for you.

mcp.dataverse.org DNS A record still 157.230.86.15 — assume backend was swapped behind the same IP.