> For the complete documentation index, see [llms.txt](https://docs.solanavibestation.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solanavibestation.com/developers/getting-started/endpoints-and-dns-load-balancing.md). # Endpoints & DNS Load Balancing Solana Vibe Station serves traffic from multiple geographic locations. By default, our endpoints use **DNS-based geographic load balancing** so your requests resolve to the nearest healthy location automatically — no configuration required on your end. You can also bypass the geo-routing and pin directly to a specific location if you want maximum control over where your traffic lands. Both options are described below. ### Available locations | Code | Location | Region | | ---- | ---------------------- | ------------- | | ATL1 | Atlanta, USA | North America | | AMS1 | Amsterdam, Netherlands | Europe | ### How geographic routing works Our default endpoints are fronted by Cloudflare Load Balancing running in **DNS-only mode**. We do not proxy your traffic — Cloudflare acts purely as an authoritative DNS responder, returning the IP address of the best location for each request. Once you have the IP, your connection goes **directly** to our origin servers. No SVS traffic is hair-pinned through a third-party proxy. This allows for the absolute lowest latency connection to our infrastructure. Two mechanisms work together: **Proximity routing.** When your DNS resolver queries one of our load-balanced hostnames, Cloudflare returns the IP of your closest healthy edge location. This happens at the DNS layer based on the location of your **recursive resolver**, so for the best geographic match we recommend using a resolver near you rather than a distant public resolver. **Automatic failover.** Each location is continuously health-checked. If a location becomes unhealthy — during maintenance, an incident, or a network issue — it is automatically pulled from DNS responses and your traffic is routed to the next healthy location. When it recovers, it is added back automatically. This failover is bounded by the DNS record's TTL (currently 10s `TTL`), so clients may briefly cache a prior result before picking up the change. ### Preferred (geo-routed) endpoints For most users, the geo-routed hostnames are the right choice. Use the standard tier hostname and let DNS route you to the nearest healthy location with automatic failover: ``` https://.rpc.solanavibestation.com https://.swqos.solanavibestation.com https://.grpc.solanavibestation.com ``` RPC tiers: `lite`, `basic`, `ultra`, `elite`, `epic`\ SWQoS tiers: `basic`, `ultra`, `elite` \ gRPC tiers: `basic`, `ultra`, `elite` Example: ``` https://elite.rpc.solanavibestation.com https://ultra.swqos.solanavibestation.com https://basic.grpc.solanavibestation.com ``` These hostnames are the recommended default. You get nearest-location performance and transparent failover with no extra work. ### Location-specific endpoints If you need **maximum control** over which location serves your traffic — for example, to co-locate with infrastructure in a specific region, to benchmark a single location, or to meet a data-residency requirement — you can target a location directly using its location-specific hostname. {% hint style="warning" %} **Trade-off:** Location-pinned endpoints **opt out of DNS failover.** If the location you pin to goes down, your requests will fail rather than rerouting to a healthy location. Use these only when deterministic location control matters more than automatic failover, and consider implementing your own fallback logic on the client side. {% endhint %} The location-specific hostname format is: ``` https://.rpc..solanavibestation.com https://.swqos..solanavibestation.com https://.grpc..solanavibestation.com ``` Examples: ``` https://elite.rpc.atl1.solanavibestation.com # pinned to Atlanta https://elite.rpc.ams1.solanavibestation.com # pinned to Amsterdam https://ultra.swqos.ams1.solanavibestation.com # SWQoS pinned to Amsterdam https://ultra.grpc.atl1.solanavibestation.com # gRPC pinned to Atlanta ``` ### Which should I use? | | Preferred (geo-routed) | Location-specific | | -------- | ---------------------------------- | --------------------------------------------- | | Routing | Nearest healthy location | Fixed location you choose | | Failover | Automatic | None — you opt out | | Best for | Most users, lowest latency | Co-location, benchmarking, residency | | Hostname | `.rpc.solanavibestation.com` | `.rpc..solanavibestation.com` | When in doubt, use the **preferred geo-routed endpoints** — they give you the best latency and resilience automatically.