# "Probe across multiple regions"
## Symptom
Users in different regions report different retrievability. You want
to confirm whether the issue is geographic (network-side) or
isolated to specific clients.
## Diagnose
Multi-vantage is the whole point. Run with `--bee` pointing at nodes
in different regions:
```bash
bee-check <ref> \
--bee https://us-east.bee.example \
--bee https://eu-central.bee.example \
--bee https://ap-south.bee.example \
--gateway https://api.gateway.ethswarm.org \
What to look for in the output:
- **Same status across all vantages.** Probably a content-level
issue (lost, garbage-collected, never pushed) — region isn't the
axis.
- **`partial` with a regional pattern.** US says yes, EU says no.
Drop into `--per-chunk` from the failing region — likely a
neighborhood-level retrieval problem rooted in that region's
peering.
- **All slow but eventually yes.** Long latencies (multi-second)
with the same status — likely overloaded chunks of the manifest;
cross-reference with `chunk_stats.per_neighborhood`.
## Useful: target-overlay framing
If you have a specific user's overlay (or you know their gateway's
overlay), pass it as `--target-overlay`. The report sorts vantages
closest-first to that overlay and tags each with `target_proximity`:
```bash
bee-check <ref> --target-overlay <user-overlay-hex> --bee ... --bee ...
```
The closest vantage to that overlay is your best proxy for "what
the user actually sees". A `retrievable` from a near vantage but
`unretrievable` from a far one is a strong signal that the user's
*network position* is the problem, not the content.
## Fix
Diagnosis-only — fixes depend on what you find. Common follow-ons:
- Stale stamps → [Re-seed from an old batch](./reseed-old-batch.md).
- Not-yet-pushed → [My upload looks lost](./lost-upload.md).
- Specific neighborhood unreachable → escalate to whoever runs Bee
nodes in that neighborhood (or run one yourself).