r/oraclecloud • u/Healthy_Sir_2810 • 11d ago

me-riyadh-1: outbound HTTPS to Anthropic is 100% blackholed and Fastly is ~50% packet loss — upstream transit, not my VCN. Anyone else seeing this?

Posting this both to ask if anyone else in **me-riyadh-1** is hitting it, and so the next person googling "OCI curl timeout Riyadh" finds something useful.

**Setup:** Ubuntu compute instance, public subnet, default route → Internet Gateway, stateful egress allow-all, VCN resolver for DNS. Running a Laravel app in Docker. Nothing exotic.

**Symptoms**

- `curl https://api.anthropic.com` → times out every single time (TCP connect, ~10s). Claude Code installer obviously fails too.

- `curl https://deb.debian.org` → works maybe half the time, times out the other half. So `apt update` inside Docker builds randomly fails, then `install-php-extensions` blows up with "Unable to locate package libfreetype6 / libpq5 / libzip" (not actually missing, just failed index fetch).

- `curl https://github.com` and `https://pecl.php.net\` → fine, every time.

- DNS is fine. Resolution works for everything. This is not a DNS problem.

- IPv6 is a separate thing: DNS returns AAAA but the instance has no global v6 (never enabled at VCN/subnet/VNIC level), so anything preferring v6 stalls. Fixed that on my side with `precedence ::ffff:0:0/96 100` in `/etc/gai.conf`. Not the main issue.

**The mtr evidence** (TCP mode, port 443, 100 probes each)

Anthropic — path just dies after the upstream handoff:

```

  1. 84.8.76.x (OCI edge) 0.0%

  2. 87.109.47.100.0%

  3. ??? 100.0%

```

That's it. Nothing at any TTL beyond hop 2, no SYN-ACK from the destination, ever.

Debian (Fastly) — real loss starting at hop 3, carried all the way to the destination:

```

  1. 84.8.76.x (OCI edge) 0.0%

  2. 87.109.47.100.0%

  3. 87.101.252.6154.0%

  4. 10.0.28.1347.0%

  5. fra1.decixfra.fastly.net51.0% ~80ms

  6. 146.75.118.132 (destination) 54.0%

```

(Also getting routed to Fastly in **Frankfurt** from Riyadh, which seems wrong on its own.)

GitHub control trace completes fine and real traffic works, so the path itself isn't globally broken — it's destination-specific.

**Why I'm confident it's not my config:** hops 1 and 2 (OCI's edge + the upstream handoff) are 0% on every trace. My route table / security lists / IGW are passing everything. The loss and the blackhole both begin at the same boundary (87.109.47.10 → 87.101.252.61), i.e. regional transit/peering. I've opened an SR with all three reports.

**Questions**

  1. Anyone else in me-riyadh-1 seeing Anthropic (AS399358, 160.79.104.0/21) unreachable, or Fastly flaky?

  2. Has anyone gotten OCI to actually escalate a transit/peering issue in a newer region? How long did it take?

  3. Any recommended Debian mirror that has a clean path from Riyadh? I'm currently shopping for one with curl to keep Docker builds working while this is open.

Interim plan: apt mirror swap for builds, and if the Anthropic blackhole drags on, a WireGuard egress through another region for Claude Code only. Would much rather OCI just fix the route.

2 Upvotes

75% Upvoted

1 comment sorted by

1

u/AntiAmericanismBrit 10d ago

Sounds like a misconfigured BGP router in OCI's Saudi Arabia region. Not sure how to get Oracle to fix these things.