Staff

@MadeUpName12 Hello! There are two separate things in your configuration. 1. Please remove the line "auth-user-pass ...". AirVPN does not use a username and password for OpenVPN: the connection is authenticated by the certificate and the key that are already inside the file built by the Config Generator, and the Config Generator never adds auth-user-pass. With that line, OpenVPN asks for a username and a password, or reads them from the file you name there. If that file is missing or cannot be read, OpenVPN stops before it connects. 2. About IPv6. Our OpenVPN servers offer IPv6 inside the tunnel to every OpenVPN client. So with OpenVPN, the IPv4-only exit setting of the Config Generator is not enough by itself, and that is why you still saw IPv6 at the exit. The line that solves it is one of the lines you added: pull-filter ignore "ifconfig-ipv6" With WireGuard, instead, the IPv4-only exit setting of the Config Generator works as expected: the WireGuard file gets only an IPv4 address and routes only IPv4 into the tunnel. In that case IPv6 is not routed into the tunnel at all, so the same note below applies: keep IPv6 disabled on your network adapters. The line with "route-ipv6" does no harm and can stay. The line with "tun-ipv6" can be removed: that option has no effect in OpenVPN 2.6. The warning comes from another option that the server sends, "redirect-gateway ipv6". It routes all the IPv6 traffic of your computer into the tunnel, so that IPv6 can never go out outside the VPN. The tunnel now has no IPv6 address, so OpenVPN warns that the IPv6 routes may not work. This is exactly what you want: IPv6 has nowhere to go. The warning is harmless, and we suggest to keep the configuration as it is. If you still want to remove the warning, you can replace that server option with an IPv4-only one, by adding these two lines: pull-filter ignore "redirect-gateway" redirect-gateway def1 bypass-dhcp After this change IPv6 is no longer routed into the tunnel. Do it only while IPv6 is disabled on all your network adapters. If Windows gets IPv6 back (for example after an update, or on a new adapter), your IPv6 traffic would go out outside the VPN. If the log window still stays open after these changes, please paste here the lines of the log from "Initialization Sequence Completed" on. If you paste the configuration again, remove the certificate and key blocks first. Kind regards

@major4579 Hello! The "Deactivate Network Lock" button you see after starting Eddie in the morning refers only to the Eddie session you just started, so it can't tell whether the overnight exit worked. When Eddie starts, it first removes any Network Lock rules left by a previous session, then it activates a new Network Lock because of --netlock in your command line or "Activate Network Lock at startup" in Preferences > General. Note that saving the Preferences from a session started with --netlock stores that option as ticked, so it may be active even if you never ticked it yourself. There is no command line switch that tells a running Eddie to deactivate the Network Lock and exit: command line options are read only when Eddie starts. Please check one thing tomorrow morning. Before you start Eddie, open a web page in your browser. Does it load? If the page loads, the batch file works. Your batch file ends with a full shutdown, and a full shutdown removes all Network Lock rules. So no rules are left from the night before. In this case, what you should change depends on what you want in the morning. If you want to be connected to the VPN: - Create a task in Task Scheduler with the trigger "At log on". - The task must start Eddie with your usual command line. - Do not use the "Start with System" option of Eddie for this. That option starts Eddie without your command line options. If you want normal internet until you connect: - In Eddie, go to Preferences > General and untick "Activate Network Lock at startup". - Remove --netlock from the shortcut or command that you use in the morning. If it does not load: please tell us what really turns the computer off. Has the previous scheduled shutdown been removed? Is it a real shutdown, or sleep or hibernation? Does the History tab (or "Last Run Result") of the task in Task Scheduler show that the batch file ran? Please also disable Fast Startup (Control Panel > Power Options > Choose what the power buttons do > Change settings that are currently unavailable > untick "Turn on fast startup"). In this case, starting Eddie removes the leftover rules by itself. In both cases, start Eddie as usual and, before you deactivate the Network Lock, publish a system report as explained here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do The line "Windows WFP, recovery of pending rules." in the log shows that rules from the previous session were really still there. @pHxaq thank you for the suggestion; the DNS problem you describe is a different symptom, and Marc has already ruled it out. Kind regards

@NL99 Hello! What you see is how the two programs work together today, not a problem with your qBittorrent installation, so a reinstall can't change it. With WireGuard, Eddie 2.26.2 on Windows creates the "Eddie" adapter when a connection starts and removes it when the connection ends. A server change is a new connection, so it gets a new adapter: same name, "Eddie", but a new identity for Windows (a new GUID and a new interface identifier). qBittorrent does not store the name you see in the list. It stores that identifier (the "iftype..." value in Session\Interface) and passes the adapter GUID to libtorrent when the setting is applied, that is at startup or when you change the setting. After a server change the old adapter no longer exists, so qBittorrent can neither send nor receive anything (it fails closed, so nothing leaks), and it does not move to the new adapter by itself. The second "Eddie" entry in the list is qBittorrent showing the saved interface that no longer exists, next to the current one. Selecting the interface again, or restarting qBittorrent, applies the setting again, and that's why both work. About qBittorrent.ini: changes there count only if qBittorrent is completely closed (tray icon included) while you edit the file, otherwise it writes its own settings back when it exits. It's easier to change these settings from the qBittorrent window. We see two options. 1. Bind to the WireGuard address instead of the adapter. In qBittorrent > Tools > Options > Advanced set "Network interface" to "Any interface" and "Optional IP address to bind to" to the IPv4 address of your WireGuard connection (10.x.x.x). You can read it in Eddie, Stats tab, "VPN IP", or with ipconfig on the Eddie adapter while connected. With WireGuard this address belongs to your device key and is the same on every AirVPN server, so the binding survives server changes: libtorrent re-opens its sockets when the address comes back on the new adapter. When the tunnel is down the address does not exist and qBittorrent can't connect, the same protection you have now. Limits: qBittorrent accepts one address only, so with an IPv4 address you will not connect to IPv6 peers; the address changes if you connect with a different device in Eddie or renew that device's key (set it again in that case); it does not work with OpenVPN, where the address can change at every connection. 2. Set "Network interface" to "Any interface" and rely on Eddie's Network Lock. Network Lock stays active while Eddie changes server, so qBittorrent can't go out of the tunnel during the switch. Note that when Network Lock is activated automatically at connection (the default), Eddie removes it when you disconnect. If you want qBittorrent to stay blocked while Eddie is disconnected too, activate Network Lock from Eddie's main window: it stays active until you deactivate it or close Eddie. If you go for option 1, you can still keep Network Lock active, as an extra protection for everything else on your system. Kind regards

Hello! We're glad to inform you that AirVPN Suite for Linux next release will include AmneziaWG support with full integration with AirVPN, similarly to Eddie Android edition. We should be able to make a preview publicly available before the end of November. Kind regards

Hello! We're very glad to inform you that the Black Friday weeks have started at AirVPN! Save up to 74% when compared to the one-month plan price Check all plans and discounts here: https://airvpn.org/buy If you're already a customer of ours and you wish to jump aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. What's new since last Black Friday OpenVPN 2.7 with Data Channel Offload (DCO) on every server. The whole network now runs OpenVPN 2.7 with the DCO kernel module, which processes encryption inside the kernel for higher throughput and lower CPU load. The Configuration Generator default profile is DCO-ready, with no deprecated directives (details https://airvpn.org/road_to_openvpn26) 17 new 10 Gbit/s full duplex servers in Amsterdam (Netherlands), London and Manchester (United Kingdom), Toronto (Canada), Los Angeles and New York City (USA) and Stockholm (Sweden) United Kingdom infrastructure fully renewed: all the old 1 Gbit/s servers were replaced by six new 10 Gbit/s servers, which raises the UK theoretical peak from 15 to 60 Gbit/s. In Sweden, the older Uppsala servers were retired in favour of new 10 Gbit/s hardware in Stockholm Total infrastructure bandwidth up by about 25%, now over 1.3 Tbit/s Faster uploads and smoother performance under load: a deep rework of server-side routing and firewall rules removed a bottleneck on busy high-speed servers, and network tuning sharply reduced packet drops Eddie Android edition 4.0 and 4.1: full AmneziaWG support alongside OpenVPN and WireGuard. It includes a built-in database of more than 30 real websites whose traffic your connection can imitate, to get past VPN blocking. Login keeps working even when our bootstrap servers are unreachable, and IPv4 and IPv6 can travel over an IPv6 tunnel with WireGuard and AmneziaWG. Version 4.1 brings improved stability, from Android 5.1 to Android 16, Android TV included Eddie desktop edition 2.26.2 for Windows, macOS and Linux (ARM included): OpenVPN 2.7, WireGuard for Windows 1.0, extensive security hardening of the privileged components, and stronger encryption of saved profiles AirVPN Suite 2.1 and 2.2 for Linux (x86-64, AArch64 and ARMv7): reworked network and default gateway detection, a new option to choose whether IPv4 traffic travels over an IPv6 tunnel, improved IPv6 handling and a security-hardened traffic splitting manager. Hummingbird 2.1.0 for macOS runs natively on both Intel and Apple Silicon AirVPN is one of the oldest and most experienced consumer VPNs on the market, operating since 2010. It never changed ownership and it was never sold out to data harvesting or malware specialized companies as regrettably happened to several competitors. Ever since 2010 AirVPN has been faithful to its mission ( https://airvpn.org/mission ). AirVPN does not inspect and/or log client traffic and offers: five simultaneous connections per account (additional connection slots available if needed) state-of-the-art and flexible inbound remote port forwarding ( https://airvpn.org/forums/topic/63545-update-remote-port-forwarding-system-expansion ) active daemons load balancing for unmatched high performance ( https://airvpn.org/forums/topic/48234-speedtest-comparison/?do=findComment&comment=131616 ) - current 'all-time high' on the client side is 730 Mbit/s with OpenVPN and 2000 Mbit/s with WireGuard flexible and customizable opt-in block lists ( https://airvpn.org/forums/topic/49876-new-feature-dns-block-lists ) protecting you from adware, trackers, spam and other malicious sources. You can customize answers or exceptions globally, at account level or even at single device level. powerful API ( https://airvpn.org/faq/api ) Full IPv6 support comfortable management of your client certificates and keys ( https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs ) OpenVPN, WireGuard and AmneziaWG (Android) connections AES-GCM and ChaCha20 OpenVPN ciphers on all servers Perfect Forward Secrecy with unique per-server 4096-bit Diffie-Hellman keys internal DNS: each server runs its own DNS server. free and open source software client-side software support for traffic splitting on an application basis on Android and Linux and on a destination basis on Windows and macOS GPS spoofing in Eddie Android edition AirVPN is the only VPN provider which is actively developing the OpenVPN 3 library with a fork that's currently 379 commits ahead of OpenVPN master and adds key features and bug fixes for a much more comfortable and reliable experience: https://github.com/AirVPN/openvpn3-airvpn AirVPN, in accordance with its mission ( https://airvpn.org/mission ), develops only free and open source software for many platforms, including Android, Linux (both x86 and ARM based systems), macOS and Windows. Promotion due to end on 2026-12-03 (UTC). Kind regards & datalove AirVPN Staff

Hello! When Windows shuts down, it closes Eddie before Eddie can disconnect and remove its Network Lock rules. With Fast Startup enabled (the Windows 10 default), Shut down does not fully reset the system, so the leftover rules are still active when you power on the computer the next day. When Eddie exits normally, it disconnects and removes the Network Lock by itself, so the solution is to let Eddie exit before Windows shuts down. 1. Add --gui.exit_confirm=False to your launch command, so that Eddie does not ask for a confirmation when it is closed: Eddie-UI.exe --path=home --batch --netlock --connect --netlock.allowed_ips=192.168.1.10 --gui.exit_confirm=False 2. Replace your scheduled shutdown with a scheduled task (Task Scheduler) that runs this batch file: @echo off taskkill /IM Eddie-UI.exe set /a n=0 :wait timeout /t 5 /nobreak >nul tasklist /FI "IMAGENAME eq Eddie-UI.exe" | find /I "Eddie-UI.exe" >nul || goto off set /a n+=1 if %n% lss 12 goto wait :off shutdown /s /t 0 taskkill without /F asks Eddie to close as if you had chosen Exit: Eddie disconnects, removes the Network Lock and exits. The batch file waits up to one minute for Eddie to exit, then shuts the computer down. In the task properties, run it under your own account with "Run only when user is logged on" and "Run with highest privileges", so that taskkill can reach the Eddie window. Please let us know whether the Network Lock is gone the next morning. Kind regards

Hello! The AirVPN Suite has no graphical interface at the moment: Bluetit runs as a system daemon, while Goldcrest and Hummingbird are command line programs. Their output is shown by your terminal emulator, so the background, text colors and font are decided by the terminal, not by the Suite. To get a dark mode, select a dark theme or profile in your terminal emulator's preferences (GNOME Terminal, Konsole, xterm and so on), and the Suite will be displayed with it. Kind regards

Hello, thank you for the report. We checked all exit addresses, IPv4 and IPv6, of our Phoenix servers (Guniibuu, Khambalia, Sheratan) and Chicago servers (Fang, Kruger, Meridiana, Praecipua, Sadalsuud, Sneden, Superba): MaxMind GeoLite2, ipinfo.io and ip-api.com all place them correctly in Phoenix, Arizona and Chicago, Illinois, US. Google and Meta use their own location data for IP addresses, which can differ from those public databases, so they can place a shared exit address in another country even when the public databases are right. We cannot edit their data directly. Google offers a form to report a wrong IP location: https://support.google.com/websearch/workflow/9308722?hl=en Submit it while connected to the affected server; Google says updates can take more than a month. If it happens again, please post the server name and the exit IP shown by https://ipleak.net at that moment, so we can check that specific address. In the meantime, a server in another city or country is the practical workaround. Kind regards

Hello! A correction to our previous update about the migration of the three Manchester servers (Bubup, Ceibo, Chaophraya). The migration to the new machines was completed today, 2026-11-11. The information we had received from the provider turned out to be correct for IPv4 only: - IPv4: the entry and exit addresses are unchanged, as announced. - IPv6: the entry and exit addresses have changed. What you need to do: Eddie, the AirVPN Suite (except Hummingbird) and the other software that downloads the server list from us: nothing. The new IPv6 addresses are picked up automatically. Configuration files generated with the Configuration Generator that use host names: nothing. Configuration files that contain the IPv6 addresses of these servers (for example with the "Resolved hosts" option, or WireGuard files with an IPv6 address in Endpoint): please generate them again. Firewall rules, routers or scripts that refer to the IPv6 addresses of these servers: please update them. Configuration files and rules that use only the IPv4 addresses of these servers remain valid. We apologize for the inaccurate information in our previous update. Kind regards & datalove AirVPN Staff

Hello! @thecoachchen, thank you for your patience and for all the logs and tests you provided. As promised, here is the outcome. After investigating with the user, we could not confirm a single root cause for the WireGuard handshake failure on that system, and the investigation is now closed without a definitive fix. Some of the findings are useful for anyone with the same symptoms: Bluetit reports "Connected", then "WireGuard handshake failed to resume" and reconnects about every minute, with no Internet access and no name resolution. 1. Upgrade to AirVPN Suite 2.2.0, the current release, before anything else. The first line Bluetit writes to the log shows the version in use ("Starting Bluetit - AirVPN WireGuard/OpenVPN3 Service 2.2.0"). Version 2.2.0 also changes how the keys of a WireGuard configuration are read. In 2.1.0 and older a key beginning with "+" is read incorrectly, and the tunnel cannot complete a handshake with any server. If you must stay on an older version, create a new device in the Client Area and use it, so that it gets new keys. 2. Do not run two VPN clients at the same time (for example Eddie and Bluetit on the same computer), and never use the same device in two places at once (for example the Suite on two computers). Each device has its own WireGuard key and VPN address, so two simultaneous sessions with the same device conflict with each other. Exit Eddie completely before you start Bluetit, and create a separate device in the Client Area for each computer. 3. If names do not resolve even before the tunnel is up, check which DNS servers the system uses while no VPN is connected: cat /etc/resolv.conf resolvectl status If they still list the VPN DNS, for example 10.128.0.1, a previous session did not end cleanly and did not restore the DNS settings. That address can be reached only inside the tunnel, so name resolution fails outside of it. The comment at the top of /etc/resolv.conf tells you which program wrote the file and where it saved the original. To restore the settings left by Bluetit, with the Bluetit service running, use: goldcrest --recover-network To restore the settings left by Eddie, start Eddie and exit it normally. 4. If, with "allowprivatenetwork yes" (the default), you can reach the devices in your own subnet but not other private subnets behind the same router (for example 192.168.1.0/24 works, 192.168.2.0/24 does not): Network Lock already allows 192.168.0.0/16, 10.0.0.0/8 and 172.16.0.0/12, but Bluetit sends traffic into the tunnel with a 128.0.0.0/1 route, which also covers 192.168.0.0/16. Only the subnet your computer is directly connected to keeps its own route. Add a more specific route to the other subnets through your LAN gateway, for example: sudo ip route add 192.168.0.0/16 via 192.168.1.1 Replace 192.168.1.1 with your gateway. To make the route persistent on Ubuntu, add it to your Netplan configuration under the interface: routes: - to: 192.168.0.0/16 via: 192.168.1.1 If the problem persists with 2.2.0, please post here: - distribution and version, and AirVPN Suite version - your DNS setup: the output of "ls -l /etc/resolv.conf" and whether you use systemd-resolved, resolvconf or NetworkManager - any other software that manages the firewall or the network on the same system (ufw, firewalld, Docker, Tailscale, another VPN) - the Bluetit log of a whole failed attempt, from the start of the connection to the first "handshake failed" line. Bluetit writes to the system log with the tag "bluetit", for example: sudo journalctl -t bluetit -b - whether the Bluetit service terminated unexpectedly, as shown by: systemctl status bluetit Kind regards

Hello! An update about the migration of the three Manchester servers (Bubup, Ceibo, Chaophraya) to new machines. We have been informed by the provider that the servers can keep their current IP addresses. After the migration Bubup, Ceibo and Chaophraya will keep the same entry and exit IP addresses, both IPv4 and IPv6. This means that no action is required on your side, whatever software or configuration you use: - Eddie, the AirVPN Suite and the other software that downloads the server list: nothing to do, as before. - Configuration files generated with the Configuration Generator, with host names or with IP addresses (including "Resolved hosts" and WireGuard files with an IP address in Endpoint): they remain valid, no need to generate them again. - Firewall rules, routers or scripts that refer to the IP addresses of these servers: no need to change them. Each server might still be unavailable for a short time during the switch. Remote port forwarding is not affected: your forwarded ports stay the same. Please ignore the previous instructions about new IP addresses. We apologize for any inconvenience if you have already started preparing for the change. Kind regards & datalove AirVPN Staff

Hello! Thank you for the screenshots, they help a lot. Windows still lists the Eddie window ("Eddie - Ready" in the taskbar preview and in Task View), so Eddie is running and its main window exists: most likely it is placed outside the visible area of your screen. Eddie restores the last saved window position at startup and checks it only roughly against the screen size, so a position saved with a different display setup (another monitor, a TV, a dock, a change of resolution or scaling) can put it where you cannot see it. Please try these steps in order: 1. Right-click the Eddie tray icon and look at the item above "Exit". If it says "Show Main Window", click it. If it says "Hide Main Window", Eddie believes the window is already shown, so go to step 2. 2. Click the Eddie button on the taskbar so that the window gets the focus, then press Win+Up, or Win+Shift+Left / Win+Shift+Right. Alternatively, with the window focused, press Alt+Space, then M, then one arrow key, and move the mouse: the window follows the mouse until you click. When it is back, exit Eddie normally from the tray icon, so that the good position is saved. 3. If that does not work, reset the saved position from the command line. Exit Eddie from the tray icon, check in Task Manager that no Eddie-UI.exe is left, then press Win+R and run: "C:\Program Files\AirVPN\Eddie-UI.exe" -path=home --gui.window.main= The window should open centred on your main monitor. Exit once from the tray icon to save that position. If you installed Eddie in another folder, adjust the path. About the config files: Eddie keeps its settings in %LOCALAPPDATA%\Eddie (C:\Users\<your name>\AppData\Local\Eddie), not in the installation folder, and uninstalling Eddie does not remove them. If default.profile is deleted while Eddie is still running in the tray, Eddie writes it back when it exits, with the same window position. So if you want to try a clean profile, exit Eddie from the tray first (you will have to log in again and set your preferences again). If none of this helps, please tell us the Eddie version (tray icon > About), whether your display setup or Windows display scaling changed about two weeks ago (new monitor, TV, dock, remote desktop or game streaming software), and send us a system report (tray icon > About > System Report), as explained here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards

@VesselWave Hello! Thank you for the quick update. We checked 0.1.3 and the three points are addressed on both platforms. While checking the Android version we noticed a few bugs, which you might like to cross-check. References are to wave-vpn-mobile v0.1.3 (commit 2a406b6). 1. Connecting can stay blocked after a failed handshake After a connection attempt without a handshake, the next Connect first refreshes the account, with a 3 second timeout (Connection.kt:162). When the timeout expires, the TimeoutCancellationException is rethrown as a cancellation (Connection.kt:247-250), so the status stays "Connecting..." with no attempt running until the user cancels. recoveryNeeded stays true (SessionWork.kt:52), so every later Connect needs that refresh to succeed within 3 seconds first, and a retry within the 60 second budget fails at once with "Wait N seconds". Also, a request cut by the timeout does not count as a failure for its URL, because the cancellation check comes first (Protocol.kt:174), so the next attempt does not move away from a URL that silently drops packets. Where our bootstrap servers are slow or blocked, users may be unable to reconnect at all. If this problem is confirmed, you might like to consider not making Connect depend on that refresh, and counting a timed-out request as a failure of its URL. 2. The whole manifest is rejected if its bootstrap part does not validate When the manifest arrives, Documents.kt:75-86 checks the bootstrap URLs and the RSA key. If any of them is missing or invalid, the whole manifest is discarded, including the server list, which may be perfectly fine. As a result, sign-in and server list refresh fail. In the same case the desktop version ignores only the bootstrap part: it keeps using the previous bootstrap URLs and key, and still accepts the new server list. Doing the same on Android would make it more robust. 3. No connectivity after a failed connect, while the app says "Disconnected" When bringing the tunnel up fails, the blocking interface is put back and the service keeps running (Connection.kt:257-264). The app shows "Disconnected" with "Couldn't connect" and the only action offered is Connect, so the device has no connectivity and the app gives no way to release the block other than a successful connection. If the block is intentional and this behavior is confirmed, it would help to say so clearly on that screen and offer an action that removes it. 4. "Only selected" with no app checked With split tunnelling set to "Only selected" and no app checked, no IncludedApplications line is written (Wireguard.kt:38-39), so all traffic goes through the VPN, while the screen says "Only checked apps use the VPN. Everything else connects directly." (AppsScreen.kt:88). This fails in the safe direction, but the text is misleading. If we find the time, we will also have a closer look at the desktop version and let you know. Thank you again for your work. Kind regards

Hello! We inform you that the three AirVPN servers located in Manchester, UK, are being migrated to new machines: Bubup Ceibo Chaophraya The servers keep the same names, configuration, hardware and 10 Gbit/s port. Their IP addresses change, both entry and exit, IPv4 and IPv6. Planned date: 2026-11-09, between 8 AM and 7 PM UTC. Each server might be unavailable for a short time during the switch. What you need to do after the switch: Eddie, the AirVPN Suite and the other software that downloads the server list from us: nothing. The new addresses are picked up automatically. Configuration files generated with the Configuration Generator that use host names: nothing, the names will resolve to the new addresses. Configuration files that contain IP addresses (for example with the "Resolved hosts" option, or WireGuard files with an IP address in Endpoint): please generate them again after the migration. Firewall rules, routers or scripts that allow or refer to the old IP addresses of these servers: please update them. Remote port forwarding is not affected: your forwarded ports stay the same. Kind regards & datalove AirVPN Staff

Hello! First of all, thank you for writing free and open source software dedicated to AirVPN. We had a quick look at both repositories. The code is careful and we did not find any telemetry and/or third-party endpoints. The client identifies itself honestly and the documentation describes our protocol accurately. We appreciate it. There are three points that affect our infrastructure, which you might like to take into account for the next releases. References are to wave-vpn-desktop at commit ce9a15fd and wave-vpn-mobile at commit 64a2be1b. 1. Periodic tunnel verification (desktop) verify_tunnel() in src/platform/linux.rs runs every 60 seconds for the whole session: the tun check for each IP family and the dns check on https://<server>_exit.airservers.org:89/check/, plus a checkdns.airvpn.org query. Any failure tears the tunnel down. Eddie runs these checks only once, right after connecting. With a 60 second loop, a short outage of the check service would disconnect every Wave VPN user at the same time, and they would all reconnect together. You might like to consider running the checks only at connection time, or much less often with some random jitter, and not disconnecting on a single failed check. 2. Latency measurement (desktop and Android) The "ping" is a TCP connection to port 443 on the first entry IPv4 of every server (src/gui.rs on desktop, vpn/Connection.kt on Android), so about 250 connections are opened and closed at every login, launch and refresh. The desktop refresh can go down to 15 seconds from the command line, and the Android manual refresh has no rate limit. A lighter probe such as ICMP echo, fewer probes in parallel, cached results with a minimum interval between refreshes, and no probes while connected (they go through the tunnel and skew the ranking anyway) would help a lot. Also, on desktop an unreachable server currently counts as 0 ms (src/documents.rs), so "Best server" ends up preferring servers that do not answer. 3. Bootstrap servers (desktop and Android) The desktop client always uses the bootstrap URLs and the RSA key from the AirVPN.json compiled into the binary and ignores the ones in the manifest (src/lib.rs, src/documents.rs). If we change bootstrap addresses or rotate the key, older builds would stop working. It might be worth storing and using the bootstrap URLs and key from the latest manifest, and keeping the embedded ones only as a first-run fallback. On Android, Protocol.kt and Session.kt send user and manifest at every refresh, always to the first URL, with no backoff while the bootstrap servers are unreachable. Trying the other URLs when one fails, with an increasing delay between retries, would make the client more robust and lighter on our side. Thank you again for your work. Feel free to ask here if anything about the protocol is unclear. Kind regards