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?

[u/Healthy_Sir_2810]

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.

[u/hypertradeworx]

on 3, deb.debian.org is fastly all the way down, so any alias that resolves into that anycast lands you back on the same lossy path. a direct mirror gets you off it, the ftp.<cc>.debian.org names and most of the official mirror list are ordinary hosts on their own transit

for the SR, ask them to name the upstream that 87.101.252.61 sits on. that usually gets it in front of their network people instead of the queue that answers packet loss tickets

[u/bobsbitchtitz]

Out of curiosity is it just tcp that has issues or does icmp fail randomly too?