LiveKit Cloud routes our users to Japan without VPN, while Germany 2 works with VPN — can we enable EU region pinning?

Hi LiveKit team,

We are using LiveKit Cloud for realtime audio/video rooms and are seeing what looks like a region-routing issue.

What we observed:

  • With VPN enabled, clients are routed to Germany 2 and the LiveKit connection test passes

  • Without VPN, clients are routed to Japan and the LiveKit connection test fails

  • In the failing case:

    • signaling connects initially

    • media transport becomes unstable

    • reconnects happen

    • audio/video publishing does not work reliably

Connection test results:

With VPN

  • Region: Germany 2

  • Pass

  • Can publish audio

  • Can publish video

Without VPN

  • Region: Japan

  • Fail

  • “Could not determine packets are sent”

  • repeated reconnects / signal disconnects

This makes us think automatic region routing is selecting an unsuitable region for our users when they are not on VPN.

Questions:

  1. Can protocol-based region pinning be enabled for our project?

  2. Can traffic be restricted to EU regions?

  3. If yes, would Germany / Germany 2 be appropriate target regions?

  4. Does our current plan support this, or would we need to upgrade?

This is currently blocking reliable external testing of our application.

I can provide:

  • project URL

  • browser logs

  • screenshots of the connection test

  • timestamps of failed sessions

Thank you.

Hi, details about protocol-based region pinning can be found at Region pinning | LiveKit Documentation

The user you are logged in as is on the Build plan, but region pinning is only offered on the Scale plan or higher, so you would need to upgrade unless you already have a separate account that I’m not seeing.

The region for EU has locations in Germany and Germany 2 but we would not recommend pinning to a specific location - In your case, pinning to EU would be most sensible.

I’m not sure what the root cause of your actual issue is, do you see anything in your client logs? It seems like it’s the clients who are failing to connect.

Hi, thanks — that helps.

Yes, we do see a pattern in the client-side behavior.

What we are seeing is:

  • With VPN:

    • routed to Germany 2

    • connection test passes

    • can publish audio/video successfully

  • Without VPN:

    • routed to Japan

    • connection test fails

    • signaling connects initially

    • TURN appears reachable

    • but audio/video publishing becomes unstable

    • connection test reports “Could not determine packets are sent”

    • repeated reconnects / signal disconnects happen afterward

So from our side it looks less like a general app bug and more like:

  • the client can reach LiveKit,

  • but the selected region / network path is not usable enough for stable realtime media.

A few follow-up questions:

  1. Does this pattern look consistent with a region/path quality issue rather than an application logic issue?

  2. On the Build plan, is there anything at all we can do to reduce the chance of clients being routed to Japan?

  3. Are there any additional client-side diagnostics you would recommend to confirm the root cause more precisely?

  4. Can you check from your side whether our project sessions show anything unusual for these failed connections?

If helpful, I can share:

  • browser console logs

  • LiveKit connection test outputs with and without VPN

  • timestamps of failed sessions

  • project details

At this point I mainly want to understand the root cause clearly, even if the final fix would require a different plan.

Does this pattern look consistent with a region/path quality issue rather than an application logic issue?

If there was a general issue with our node in that region then I would expect to see a lot more reports, so I suspect something more nuanced is happening.

On the Build plan, is there anything at all we can do to reduce the chance of clients being routed to Japan?

No, there aren’t any other levers you can pull with LiveKit cloud. Technically you could self-host LiveKit server and handle the routing yourself, but that would be an extreme solution.

Are there any additional client-side diagnostics you would recommend to confirm the root cause more precisely?

The client SDK logs might contain something. I know you have tried with Connection Tester | LiveKit, but I mean an actual LiveKit client.

Can you check from your side whether our project sessions show anything unusual for these failed connections?

Sure, if you give me some session IDs (they start with RM_) I can take a look at our server logs, but that would depend on the connection reaching LiveKit server.