What “simultaneous connections” means

Simultaneous connections usually refers to the number of active, concurrent sessions you can have at the same time using the same account or identity. In a VPN context, it typically describes how many separate device sessions (or “tunnels”) can be established concurrently without the system closing an existing one.

It matters because the limit changes user experience: you might be able to browse on one device but see connection failures, forced disconnects, or automatic swapping of sessions when you try to add more devices.

How simultaneous connections typically work

While implementations vary, the underlying pattern is common:

  • A connection attempt requests an active session to be created.
  • The service (or client) counts that session against a concurrency allowance.
  • If you are still under the limit, the session is established and continues running.
  • If you are at or above the limit, the system applies a rule—often failing the new attempt, disconnecting an existing session, or requiring you to reconnect.

Some systems also differentiate between connection states. For example, a session that is “connecting” or “reconnecting” may still be counted temporarily, depending on how the service tracks sessions. That can make the effective limit feel inconsistent until you fully stop one session and wait for it to clear.

Common limitations and what can change the outcome

The single most important limitation is that the definition of “simultaneous” is often not what you expect.

  • Per account vs per device: The limit may be enforced per account (all devices combined), rather than per device.
  • Per app profile or per client instance: Some setups count multiple client instances on the same device as separate sessions.
  • Counting “active” vs “attempted” sessions: Quick reconnect attempts can temporarily increase the count.
  • Automatic reconnection behavior: If the client rapidly reconnects after a drop, it may briefly create overlapping attempts.

A practical consequence: if you see problems when adding a second or third connection, it may not be the number of devices you think you have active—it may be the number of sessions the service still considers active.

Practical checks you can do

Because exact rules are provider- and configuration-dependent, focus on checks that reveal the limit behavior in your own setup.

  1. Confirm how many sessions are truly active. On each device, verify whether the VPN is connected (not just enabled) and whether traffic is flowing.
  2. Introduce one change at a time. Start with one connected device. Then add a second, observe whether it connects cleanly, and note any error or disconnect.
  3. Look for explicit limit-related messages. Many clients display messages when concurrency is exceeded—sometimes wording like “too many connections,” “session limit,” or a forced disconnect reason.
  4. Restart cleanly when testing. Stop/disconnect the VPN on one device, fully quit the client (or restart the device/client), and then wait briefly before retrying on the other device to avoid overlapping “reconnecting” states.
  5. Check account or client settings. Some clients include a concurrency indicator, a “number of devices” view, or a setting that changes how sessions are handled.

If you cannot reproduce the behavior reliably, repeat the test more slowly. Network fluctuations can mask the real concurrency limit by causing reconnect loops.

“Simultaneous connections” is sometimes confused with other restrictions that produce similar symptoms:

  • Speed limits or bandwidth caps: These usually don’t prevent connection establishment; they reduce throughput.
  • Rate limits or throttling: Those affect performance over time rather than blocking new sessions.
  • Routing or server capacity issues: These can cause connection failures even when you are below a concurrency limit.
  • Protocol or configuration incompatibilities: Different client settings can lead to connection issues that are unrelated to concurrency.

If your second connection fails while the first remains stable, concurrency is a plausible cause. If both connections degrade at the same time, bandwidth or server load may be more likely.

How to interpret unexpected results

Unexpected outcomes often come from session state and timing:

  • You disconnect on one device but it appears to remain “counted” for a short period.
  • The client keeps reconnecting, creating multiple attempts.
  • One device is “connected” in the UI but not actually routing traffic.

A useful mindset is to treat the reported simultaneous connection limit as a rule about active sessions as the system perceives them, not only about what you see at a glance.

If you share your specific error text and the client/device types (without needing personal credentials), you can narrow down whether the behavior matches concurrency enforcement or another restriction.