Повечето проблеми с VPN се свеждат до няколко причини и ако ги проверите в правилния ред, ще си спестите една вечер. Изпълнявайте командите на сървъра, освен ако стъпката не казва друго. Примерите използват WireGuard на стандартния порт 51820/udp; за OpenVPN или Xray заменете с името на вашата услуга и вашия порт.
Последна проверка 2026-11-13.
1. Сървърът на план със собствен IPv4 ли е?
VPN клиентът се свързва към вашия сървър отвън. NAT планът пуска отвън само един порт — личния ви SSH порт, затова на него не може да работи никакъв VPN. Ако панелът показва адрес с порт от вида 20xxx, вие сте на NAT. Преминаването към собствен IPv4 запазва данните ви и не изисква преинсталиране; вижте Смяна на IP адреса.
2. Работи ли услугата?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
При OpenVPN услугата обикновено се казва openvpn-server@server, при Xray — xray. Услуга, която не е стартирала, почти винаги пише причината в последните редове на лога си: печатна грешка в конфигурацията, липсващ файл с ключ, вече зает порт.
3. Слуша ли на порта, който очаквате?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN през UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN през TCP
Празен изход означава, че услугата не слуша там, каквото и да пише в конфигурацията. Сравнете порта с този в клиента.
4. Пропуска ли го защитната стена?
ufw status verbose
Ако защитната стена е включена и портът ви го няма в списъка, отворете го:
ufw allow 51820/udp
Внимавайте с протокола: на WireGuard му трябва UDP, а правило за 51820/tcp не му помага с нищо. Преди да включите или презаредите защитната стена, оставете правилото за SSH на мястото му, иначе сами ще си затворите достъпа. Ако все пак се случи, конзолата в браузъра в панела ще ви върне вътре.
5. Стига ли клиентът изобщо до сървъра?
При WireGuard това показва handshake:
wg show
latest handshake: N seconds ago при даден peer означава, че клиентът е стигнал до сървъра и ключовете съвпадат. Ако ред с handshake изобщо няма, клиентът така и не е стигнал. Тогава проверете поред: IP и порта на endpoint в конфигурацията на клиента, защитната стена от стъпка 4 и дали публичният ключ на клиента е в блока [Peer] на сървъра (и обратното).
6. Свързва се, но нищо не се отваря?
Тунелът работи, но сървърът не пуска трафика към интернет. Проверете препращането:
sysctl net.ipv4.ip_forward
Трябва да излезе 1. Ако не е така, включете го за постоянно:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
После проверете NAT правилото. В конфигурацията на WireGuard това е редът PostUp с MASQUERADE, а името на интерфейса в него трябва да е истинското име на интерфейса на сървъра:
ip -br addr
Ако в реда пише -o eth0, а интерфейсът ви се казва другояче, поправете конфигурацията и рестартирайте услугата.
7. Опитайте от друга мрежа
Свържете се през мобилни данни вместо през домашния Wi-Fi или помолете някого в друга държава да опита. Ако там VPN работи, а от обичайната ви мрежа — не, сървърът е наред и нещо по пътя блокира връзката.
- За да видите дали сървърът ви изобщо е достъпен от определена държава: Как да проверите дали IP адресът на вашия VPS е достъпен от Русия и Иран.
- Там, където WireGuard и OpenVPN се разпознават и блокират, VLESS + Reality изглежда като обикновен HTTPS и е много по-трудно да бъде блокиран.
8. Все още не става?
Отворете тикет и напишете какво сте проверили: изхода от стъпки 2–5 и името на вашия VPN клиент. С тези данни обикновено още в първия отговор можем да кажем къде е проблемът.
Коментари
Още няма коментари. Бъди първият.