cloudflare / cloudflare/workerd

fetch() to public ArcGIS / IIS server fails with opaque `internal error; reference = …` in local dev

Open
#6,746 2 comments 2 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
8.7k
Forks
739
Avg merge
2d 20h
Merged PRs (30d)
174

Description

## Summary

`fetch()` from inside workerd (via `@cloudflare/vite-plugin` local dev) fails for every request — `GET` or `POST`, simple or complex — to `https://mapping.gw.govt.nz` with `internal error; reference = `. `error.cause` is `undefined`. The same URL works fine from `curl` and Node's built-in `fetch` on the same machine.

## Repro

```ts
// inside any worker handler
const r = await fetch("https://mapping.gw.govt.nz/arcgis/rest/services?f=json");
```

Result:

```
Error: internal error; reference = pts8va8f3j9cntmpsq2u30sh
at
cause: undefined
```

From the same shell, `curl` and `node -e 'fetch(...).then(r => r.text())'` both succeed (200, valid JSON).

## Server details

- `Server: Microsoft-IIS/10.0`
- TLS: TLSv1.2 / `ECDHE-ECDSA-AES256-GCM-SHA384`
- Cert: `*.gw.govt.nz`, issuer `DigiCert, Inc. / GeoTrust G5 TLS ECC P-384 SHA384 2022 CA2` (publicly trusted)
- Supports both HTTP/2 (h2 ALPN) and HTTP/1.1
- IPv4 only: `192.88.190.25`

## Ruled out

- VPN / corporate proxy: none active.
- TLS interception: cert issuer seen on the client matches the genuine DigiCert chain above.
- Local firewall: Little Snitch was the prime suspect (per the closed workers-sdk#10947) and has been **fully uninstalled**. Error persists.

## Versions

- `wrangler` 4.88.0
- `workerd` 1.20260504.1
- `@cloudflare/vite-plugin` 1.36.0
- macOS Darwin 25.3.0

## Why this matters

The error message gives no actionable signal — no `cause`, no status, no protocol-layer detail. It's indistinguishable from the TLS-trust failures discussed in #5286 / workers-sdk#10947, but those have known fixes (NODE_EXTRA_CA_CERTS / disable VPN); this one doesn't, since the cert chain is publicly trusted and there's no MITM on this machine. Likely a workerd/BoringSSL handshake issue with this specific server's TLS or HTTP/2 config (possibly ECDSA + ECC P-384 chain), but without surfaced error details it's not diagnosable from JS or app-level logs.

Related: #5286 (proposes surfacing TLS errors).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.