Leaderboard

That is what the packet loss metric is for. It is the absolute indicator on whether the server line is troubled and so definitely causes problems for everyone. With that said, it's only shown if it's above 20%, as a server problem in the status log, but 10% packet loss can equally be destructive to some experiences, and 10% is not shown. In the API, for <20% the health key will still value ok, which is actually not quite ok. I mean, if you stream something with 10% packet loss via VPN, you can be sure that DASH streams at least will be inconsistent and wildly change quality. My vote is for that metric to be shown, also in the API – if I had a vote. Apologies. The majority of such feature requests are made by people who gave up troubleshooting somewhere, not exhausting all options. Most of all, the option of asking for help. Once their own (limited) repertoire of ideas runs dry, it must be the server, they conclude – while others still manage to max out their line on that same server. Must be the server, it's definitely not me, I tried everything under the sun. Probably only under their sun. And you can take my word for it as someone who roamed these forums for, I believe it's 13 years, now. It's a repeating leitmotif. Might've worded it less confrontationally, I admit. 🙏

Thanks @Tech Jedi Alex I'll post here if I find out.

Hello! This is an interesting smearing message that occasionally comes out, trying to exploit the forum we keep open for the community, for some hidden purpose or, we guess, just for hate. You can easily verify that every defect mentioned by the OP is either false or distorted. A community moderator provided some corrections that disprove the OP's claim, here we would like to add just three remarks on subjects we care about: interoperability with other VPN services, infrastructure stability and how good our remote port forwarding system is. We also want to quickly make you aware that the OP never opened a ticket for professional support, so he/she was probably not interested in a solution of his/her problems, but maybe only in building a case based on false or fabricated premises. 1. Eddie Android edition, AirVPN Suite and Eddie Desktop edition allow connections to any VPN supporting either OpenVPN or WireGuard through the most standardized method that can exist, the supported profile for each VPN application (much better than any API, especially when it does not exist on most VPN services). 2. Over the past 16 years AirVPN infrastructure constantly evolved toward more stability and speed, it's all in the records. In AirVPN we have had and we have users connected CONTINUOUSLY for SEVERAL MONTHS. Enough for connection stability? 😉 We could have even longer periods, if it wasn't for the necessity to reboot a server periodically for kernel upgrades. 3. Implementing remote inbound port forwarding over a VPN by having the VPN server use UPnP/NAT-PMP/PCP to dynamically open ports on behalf of clients is generally considered a poor architectural choice because: UPnP was designed for trusted, local networks No authentication in classic UPnP IGD exists Race conditions in a large infrastructure like AirVPN's one becomes an architectural problem UPnP would make "hot change" and other interesting features appreciated by AirVPN customers impossible Privilege escalation. UPnP used outside a local network facilitates various exploits including privilege escalation. The VPN server already controls firewall rules, NAT, routing and connection tracking. Using UPnP as an intermediary adds another protocol layer rather than configuring those systems directly. This depends on your design philosophy, but at the moment management does not see favorably functionality duplication. At the end of the day, such a poor choice would pose a bunch of problems for essentially nothing, as selecting a random port with the additional features is a matter of seconds. Kind regards