@Yang

Thank you very much. Port forwarding has resumed normal operation again. It was an issue with the Windows 11 firewall. Although the firewall had previously been turned off, at some point it was automatically re-enabled—probably due to a Windows 11 policy. Once I disabled it again, everything worked fine. Thank you. I really appreciate your help.

eMule. I’ve already made sure that the eMule listening port matches the VPN’s forwarded port. Yet I still get a Low ID, whereas before I used to get a High ID. That shouldn’t happen—ideally, once the VPN tunnel is successfully established and the server forwards the port, the client should be able to communicate over that port through a properly open public network. The ISP can’t possibly intercept a port’s communication through the VPN tunnel, right?

Of course, none of my applications can connect through the forwarded port, and changing the port doesn’t solve the problem either.

There’s nothing listening on the port? I’m using Windows 11, the network firewall is turned off. I’m currently using Eddie version 2.24.6. Is port listening managed by Eddie? Is it an issue with my computer system? I switched to using Eddie on Android and still got connection refused. What should I do?

Is it my ISP blocking it? It used to work fine before, but it recently stopped working.

Hello, I can connect to the server, but port forwarding is not working. A port test shows "connection refused." I need help.

Thank you for your guidance.

I'm using China Broadcasting Network, and ever since I started using AirVPN, I've mainly used it for P2P sharing. After all, I first came across AirVPN through an ad on an eMule website, so I've always wanted to improve speed and connection duration. Unfortunately, due to advanced traffic shaping technologies, my connection has become slower and slower, eventually getting reset. At first, I had speeds of over 150 Mbps, but they gradually dropped to 8 Mbps, and after about 10 hours, the connection finally disconnected. I think my network environment poses a significant challenge for both VPNs and P2P networks. In the future, I may no longer use AirVPN for P2P sharing, and instead just use it for browsing. The basic circumvention service that AirVPN provides still works quite well for that purpose.

Your explanation was very clear, thank you. Although I'm not a professional programmer, I can understand it.

你的解释很清楚，谢谢。虽然我不是专业的程序员，但我能理解。

In your situation, you can only use Tor. It routes your traffic through global nodes, which are impossible to block entirely. Use obfuscated bridges like Tor's webtunnel, and run AirVPN over Tor—but keep in mind, it's very slow.

Hello, I am a user from Mainland China. Over long connections, both SSH and SSL get blocked and the connection is reset, so none of the Eddie-supported protocols can maintain a long-term connection. Only the AmneziaWG protocol can sustain long connections without speed degradation—and it’s even faster and more stable than standard WireGuard. However, switching servers with AmneziaWG is somewhat cumbersome. I would like to ask: could future versions of Eddie support the AmneziaWG protocol? I believe it could completely replace standard WireGuard. This would be a huge benefit for AirVPN users behind the firewall. The AmneziaWG protocol’s source code is open-source on GitHub under the MIT license and supports free commercial use. I strongly hope Eddie can add support for AmneziaWG. Thank you!

Hello, I am a user from mainland China. During my usage, I've noticed that many servers with low load bandwidth usage are actually slower, such as those in Taiwan and Japan. I’d like to offer a suggestion to AirVPN. Personally, I believe the evaluation criteria for server quality should be based on CPU usage over a certain period, such as the average CPU usage over half an hour, rather than load bandwidth. I’ve frequently encountered handshake timeouts when connecting to "sulafat," even though the displayed load bandwidth isn’t high. I suspect this is most likely related to high CPU usage on the server, which causes key resolution timeouts. If I could connect to a server with relatively idle CPU resources, I think the connection quality would be much better. After all, speed is closely tied to protocol overhead. For example, if a 1 Gbit/s server is connected to 100 users using the WireGuard protocol, the server’s load bandwidth might reach up to 900 Mbit/s. However, if it’s connected to 100 users using SSL + OpenVPN TCP protocol, the load bandwidth might only be 400 Mbit/s. Clearly, the latter scenario places a higher burden on the server, yet the load bandwidth appears lower. Therefore, I believe servers with lower CPU usage offer better quality, rather than those with lower load bandwidth. Using average CPU usage as a metric seems more scientific to me. Does my point make sense? Does anyone agree with what I’m saying? Thanks.

Happy Birthday!!!

Hello, This is still about the driver issue. By default, Eddie checks the option "Remove adapter when session ends" in the Networking settings. This means that when the OpenVPN connection is disconnected, the Eddie program will not only remove the tunnel but also uninstall the Eddie Tunnel network adapter driver. The next time you connect, Eddie will reload the driver. On Windows, reloading the same driver means the system loads multiple instances of it. To differentiate between them, Windows helpfully adds a number to the network adapter name, such as "Eddie 99." Of course, this number doesn’t keep increasing indefinitely—it caps at 99. After "Eddie 99," the next increment rolls back to "Eddie 1." Obviously, this doesn’t affect normal usage. If this detail bothers you, you can uncheck the "Remove adapter when session ends" option in the Networking settings. However, after unchecking it, you’ll receive a warning from Eddie (in version 2.24.6), which can be annoying. Note that Eddie 2.21.8 does not issue this warning. I also hope future versions of Eddie will remove this warning. Hope this helps!

Hello, I also encountered this issue, but fortunately, I resolved it. I found that it's related to a system driver problem. For WireGuard to run, it requires the `wireguard.sys` driver. However, Eddie does not create `wireguard.sys` when there are other versions of `wintun.sys` in the system folder, which causes it to fail—quite strange. The solution is to delete all `wintun.sys` and `wireguard.sys` files in the `C:\windows\system32\drivers\` directory, then use a cleanup tool to scan the registry. After restarting your computer, open Eddie, first select the WireGuard protocol (port 51820) to connect to the server, and then switch to the OpenVPN protocol to connect again. This ensures both drivers are installed correctly. In Eddie 2.24.6, WireGuard uses `wireguard.sys`, while OpenVPN uses `wintun.sys`. Hope this helps you solve the problem!