Większość problemów z VPN sprowadza się do kilku przyczyn, a sprawdzenie ich we właściwej kolejności oszczędza cały wieczór. Polecenia uruchamiaj na serwerze, chyba że krok mówi inaczej. Przykłady używają WireGuard na domyślnym porcie 51820/udp; dla OpenVPN lub Xray podstaw nazwę swojej usługi i swój port.
Ostatnio sprawdzono 2026-11-13.
1. Czy serwer jest na planie z własnym IPv4?
Klient VPN łączy się do twojego serwera z zewnątrz. Plan NAT wpuszcza z zewnątrz tylko jeden port, twój osobisty port SSH, więc żaden VPN nie może na nim działać. Jeśli panel pokazuje adres z portem w rodzaju 20xxx, masz NAT. Przejście na własne IPv4 zachowuje dane i nie wymaga ponownej instalacji; zobacz Zmiana adresu IP.
2. Czy usługa działa?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
W OpenVPN jednostka zwykle nazywa się openvpn-server@server, w Xray — xray. Usługa, która się nie uruchomiła, prawie zawsze podaje przyczynę w ostatnich linijkach logu: literówka w konfiguracji, brakujący plik klucza, zajęty port.
3. Czy nasłuchuje na właściwym porcie?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN przez UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN przez TCP
Brak wyniku oznacza, że usługa tam nie nasłuchuje, cokolwiek mówi konfiguracja. Porównaj port z tym w kliencie.
4. Czy zapora go przepuszcza?
ufw status verbose
Jeśli zapora jest włączona, a twojego portu nie ma na liście, otwórz go:
ufw allow 51820/udp
Uważaj na protokół: WireGuard potrzebuje UDP, a reguła 51820/tcp nic mu nie daje. Zanim włączysz lub przeładujesz zaporę, zostaw regułę dla SSH, inaczej sam się odetniesz. Jeśli mimo to tak się stanie, z powrotem wpuści cię konsola w przeglądarce w panelu.
5. Czy klient w ogóle dociera do serwera?
W WireGuard mówi o tym handshake:
wg show
latest handshake: N seconds ago przy peerze oznacza, że klient dotarł do serwera i klucze pasują. Brak linii z handshake oznacza, że nigdy nie dotarł. Wtedy sprawdź po kolei: IP i port endpointu w konfiguracji klienta, zaporę z kroku 4 oraz to, czy klucz publiczny klienta jest w bloku [Peer] na serwerze (i odwrotnie).
6. Łączy się, ale nic się nie otwiera?
Tunel działa, ale serwer nie wypuszcza ruchu do internetu. Sprawdź przekazywanie:
sysctl net.ipv4.ip_forward
Wynik musi być 1. Jeśli nie jest, włącz je na stałe:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Potem sprawdź regułę NAT. W konfiguracji WireGuard to linia PostUp z MASQUERADE, a nazwa interfejsu w niej musi być prawdziwą nazwą interfejsu serwera:
ip -br addr
Jeśli w linii jest -o eth0, a twój interfejs nazywa się inaczej, popraw konfigurację i uruchom usługę ponownie.
7. Sprawdź z innej sieci
Połącz się przez internet mobilny zamiast domowego Wi-Fi albo poproś kogoś w innym kraju, żeby spróbował. Jeśli tam VPN działa, a z twojej zwykłej sieci nie, serwer jest w porządku, a połączenie blokuje coś po drodze.
- Żeby sprawdzić, czy twój serwer jest w ogóle osiągalny z konkretnego kraju: Jak sprawdzić, czy IP twojego VPS jest osiągalne z Rosji i Iranu.
- Tam, gdzie WireGuard i OpenVPN są rozpoznawane i blokowane, VLESS + Reality wygląda jak zwykły HTTPS i znacznie trudniej go zablokować.
8. Nadal nie działa?
Otwórz zgłoszenie i napisz, co już sprawdziłeś: wynik kroków 2–5 i nazwę swojego klienta VPN. Z tym zwykle już w pierwszej odpowiedzi mówimy, gdzie jest problem.
Komentarze
Brak komentarzy. Bądź pierwszy.