All LA servers keep having issues

[haruka_ff 0]

This is really a recurring issue now and you might have known this already, but this is really affecting the experiences: https://airvpn.org/issues/  

Half of the recent issues are US west servers having packet losses, and while the status showing around 30% packet loss, in reality those servers just stop replying completely for a little while.

[Staff 10655]

Hello!

We checked our infrastructure monitoring data and can confirm recurring connectivity issues, concentrated on our five Los Angeles servers, not on all West Coast servers though. The recorded issues predominantly affect IPv6. If your VPN tunnel is established over IPv6, it is indeed very likely that these incidents explain the temporary complete loss of connectivity you describe.

The packet-loss percentage on the status page reflects results from multiple monitoring locations. A reading of around 30% does not mean that every connection loses 30% of its packets: connectivity from a particular network can fail completely while other paths remain available.

Is your VPN tunnel established over IPv4 or IPv6? We mean the address used to connect to the VPN server, rather than whether you access IPv6 destinations inside the tunnel. Please also provide the affected server names and, if possible, an approximate incident time with your time zone, so we can correlate your experience with our monitoring.

We apologize for the recurring IPv6 interruptions and we will open a request for investigation with the provider.

Kind regards
 

[haruka_ff 0]

Hi,

I connect via IPv4 to mainly Sarin and Revati servers though. the last issue I had was to Revati, around 07:35 UTC.

[Staff 10655]

Hello!

Thank you, that clarification helps. Since your tunnel endpoint is reached over IPv4, the recurring IPv6 pattern we mentioned does not explain your experience.

We see ICMPv4 nearby packet-loss reports for the servers you named: Sarin at about 07:20 UTC and Revati at about 07:58 UTC. These are close to, but do not exactly match, the 07:35 UTC time you reported. They come from distributed monitoring probes, so they cannot confirm what happened on your particular route.

Could you tell us which VPN protocol and client you use, and whether the VPN connection itself disconnected or stayed connected while traffic stopped? If available, please also share the connection log covering a few minutes around 07:35 UTC, with any keys or credentials removed. This should help us compare the event with the server and network records.

Kind regards
 

[haruka_ff 0]

Hi,

I used wireguard on port 1637. The connection stayed connected as wireguard doesn't have the concept of "disconnection" on packet loss; what I saw was that there are outgoing packets, but 0 incoming packets.

I also checked the logs, and you are right, it did happen around 07:58 UTC as around that time I tried to switch to another server. Unfortunately, as there is no "disconnection" due to packet loss, I don't have other logs about it. (I use wiresock as I need per-application split tunnel.)

Edited ... by haruka_ff

[SurprisedItWorks 54]

Quick note: I've been so frustrated the past few months with Los Angeles servers, especially since they are the US "best" so often, that I actually coded up a tiny daemon for my routers to have them detect those servers and if found, automatically switch OpenVPN to a non-L.A. server.  The Los Angeles servers have been so bad that I'm not comfortable leaving family to deal with them all day.

In other words, this issue isn't about one user at one particular time.  There's a bigger problem here.

Broader observation: Before the huge influx of former Mullvad users, I changed OpenVPN servers by hand a few times a year.  Now it's generally every day and often multiple times daily, no matter where (in the US, where I generally "am") those servers are, because the delays and stoppages become intolerable.  I don't know if it's about flood attacks, datacenter issues, or simply too many users.  I love Air for its features, transparency, and strong support, but this downside is real.  (I'm on OpenVPN 2.7.5 with DCO on three router models, all running a recent dd-wrt build using a linux 6.12 kernel.  Multiple Air accounts are involved.)

[pHxaq 3]

On 10/5/2026 at 5:42 AM, haruka_ff said:

This is really a recurring issue now and you might have known this already, but this is really affecting the experiences: https://airvpn.org/issues/  

Half of the recent issues are US west servers having packet losses, and while the status showing around 30% packet loss, in reality those servers just stop replying completely for a little while.

I posted about Flegetonte - AirVPN when the server was announced, it shows a huge list of issues every single day. Clearly, from my experience using this and a few others, there's something broken in some servers.

[Staff 10655]

Hello!

Thank you for the additional details and for correcting the incident time to October 5 at 07:58 UTC. We found a matching IPv4 reachability alarm for Revati, so our investigation includes IPv4 as well as IPv6.

Our capacity measurements rule out sustained server overload from “too many users” during the period reviewed. We checked all five Los Angeles servers over September 29 - October 6:

• Peak sampled total CPU utilization remained below 36% on every server.
• Memory utilization remained below 5.6%.
• Connection-tracking table occupancy remained below 61% of capacity.
• The highest traffic rate measured over approximately five-minute intervals was 6.1 Gbit/s in both directions (6.1 + 6.1 = 12.2), on 10 Gbit/s full-duplex interfaces.

At the reported time, Revati's total CPU utilization was approximately 20–24%, and its connection-tracking table was about 30% full. These measurements show substantial capacity headroom. They do not, however, exclude very brief network events or issues affecting individual paths or queues.

We are investigating the recurring connectivity interruptions internally and are evaluating involving the provider to help establish their cause. The cause has not yet been confirmed. As previously explained, a partial failure percentage across our monitoring probes can coincide with a complete interruption on a particular customer's path.

We appreciate the reports you have provided.

Kind regards

 

[Staff 10655]

Hello!

We believe we have identified the main cause of the recurring Los Angeles connectivity issues and have deployed measures that may have resolved them. Our monitoring shows a clear improvement, but we would appreciate your help confirming the results in everyday use.

Could you please test the Los Angeles servers again and let us know whether you still experience interruptions or traffic stalls? If an issue recurs, please include the server name and the approximate time with your time zone so that we can correlate it with our monitoring.

Thank you in advance!
Kind regards