Уебсайтът е изключен, но сървърът е достъпен? Проследете отказа от DNS до приложението

„SSH работи, сайтът не” — Начнете с правилния въпрос

Алертите начват да се задействат, потребителите казват, че сайтът е мъртъв, и първият ви тест ви дава странен вид облекчение: SSH все още ви пуска. Този момент се чувства успокояващо, защото сървърът не е изчезнал. Но това е също място, където много лошо отстраняване на неизправности започва, защото „все още мога да влезя” не е същото като „уебсайтът трябва да работи.”

Полезният въпрос не е „какво мога да рестартирам първо?” Той е „кой слой се провали първи?” Работеща SSH сесия доказва, че машината е достъпна на порт 22. Тя не доказва, че домейнът се разрешава правилно. Тя не доказва:

• портовете 80 и 443 са достъпни
• HTTPS е здравословен
• приложението зад уеб сървъра отговаря

Това ръководство е построено около това разграничение и остава фокусирано върху диагностиката, вместо да се опита да стане пълно ръководство на nginx, DNS, TLS, Docker или база данни.

⚠️ Внимание: Сляпото рестартиране на nginx, Docker, PHP-FPM или целия VPS в първите минути на инцидент може да изтрие уликите, които ви трябват. Събрете един кръг доказателства първо, след това променете само слоя, който действително се провали.

Картата за триаж от една минута

Преди да навлезете дълбоко, ориентирайте се. Формата на отказа често ви казва кой слой заслужава внимание първи, дори когато все още не знаете основната причина.

Третирайте следната таблица като преки пътища за триаж, а не като окончателен вердикт.

Важното е първият счупен етап. Ако DNS се провали, по-нататъшните слоеве са шум. Ако 443 отговори, но TLS се провали, приложението все още не е ваш първи въпрос. Менталният модел по-долу е това, което прави тази последователност логична вместо случайна.

Защо SSH не доказва, че уебсайтът работи

SSH и уеб трафикът са различни пътища с различни задачи. SSH на порт 22 доказва, че можете да достигнете машината чрез нейната врата за дистанционно управление. Уебсайтът зависи от портове 80 и 443, плюс слоевете зад тях. Това са отделни тестове, така че “сървър достъпен” и “уебсайт достъпен” не са взаимозаменяеми твърдения.

Най-лесният начин да си го представите е като офис сграда. DNS помага на посетител да намери адреса на сградата. Портове 80 и 443 са рецепцията за публични посетители. Уеб сървърът е рецепционистката, която приема заявката и решава къде да отиде по-нататък. Приложението е офисът, който извършва реалната работа. База данни или друга зависимост може да се намират по-дълбоко в сградата. SSH е напълно различен вход. Полезен е за персонала, но не доказва, че рецепцията е отворена или че предаването на офиса работи.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Когато хората казват, че услуга “слуша”, те имат предвид, че тя действително приема връзки на очаквания край. Това е разграничението, което превръща неясния момент “сървърът е включен” в проследим път на заявката.

Това е важно, защото HTTPS може да се провали преди приложението да отговори, а отказите на прокси или приложение могат да се случат, след като интерфейсът вече е достъпен. Така че следващият ход е винаги един и същ: погледнете отвън първо и намерете последния успешен етап на заявката.

Стъпка 1: Възпроизведете отказа отвън сървъра

Начнете от страната на клиента, не отвътре в VPS. Ако е възможно, тествайте първо от друга мрежа или устройство, за да не объркате локален DNS кеш, стара запис в /etc/hosts или локален проблем с firewall/VPN с реален отказ на сървъра.

Използвайте подробен външен запрос, за да видите докъде стига заявката преди да се провали:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v не е инструмент само за експерти тук. Прочетете го като трасировка на напредъка. Ако никога не разрешава името, вие сте в DNS клона. Ако се свързва и след това казва Connection refused, хостът отговори, но нищо полезно не приема трафик там. Ако виси до timeout, мислете за филтриране, маршрутизиране или по-дълбока виса по-късно в пътя на заявката. Ако получите HTTP отговор, дори страница с грешка, вече сте преминали слоя на свързване и сте в по-висок клон.

💡 Съвет: Сравнете IPv4 и IPv6 рано. Забравен AAAA запис може да направи отказа да изглежда непоследователен, защото някои клиенти предпочитат IPv6 първо, а други не.

Изпълнете същия тест веднъж за всяко семейство протоколи, когато dual stack е в игра:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Ако IPv4 работи и IPv6 се провали, или обратното, вече сте стеснили инцидента по-бързо, отколкото рестартирането на услуга някога би направило. Ако отказът започва при разрешаване на имена или избор на дестинация, DNS е следващият чист клон за проверка.

Стъпка 2: Проверете DNS и потвърдете правилната дестинация

Преди да отстранявате nginx, потвърдете, че домейнът наистина изпраща посетители на сървъра, който мислите. Това е особено важно след миграции, промени на IP адреса, CDN корекции или частични редакции на записи.

Първо проверете публичните записи:

dig +short A example.com
dig +short AAAA example.com

Тези два реда отговарят на много практичен въпрос: къде интернетът вярва, че example.com се намира в момента? Един често срещан вид отказ е, че SSH по IP достига новия VPS, но домейнът все още сочи към стария адрес. Друг е, че A записът е актуализиран, но AAAA записът все още сочи някъде остарял. В този случай само част от трафика ви се проваля.

📝 Забележка: curl --resolve е по-безопасен от промяната на публичния DNS по време на инцидент. Позволява ви да тествате произхода, който възнамерявате да използвате, докато запазвате хоста и SNI неповредени.

Използвайте curl --resolve, за да принудите тест срещу IP адреса, който очаквате, без да докосвате публичните записи:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Ако това работи, докато публичният домейн все още се проваля, сървърът може да е добре и DNS може да е все още счупеният слой. Една забележка за ограничен CDN си струва да се има предвид тук. Ако вашият произход е заключен да приема трафик само от CDN IP диапазони, директен тест на произхода може да се провали просто защото произходът очаква трафик от край, а не произволни публични заявки. След като дестинацията е потвърдена, следващият въпрос е дали нещо полезно отговаря на 80 или 443 там.

Стъпка 3: Проверете какво слуша на 80/443

Сега преминете на сървъра и задайте конкретен въпрос: има ли нещо, което действително приема уеб връзки на очаквания портове? Машината може да е активна, SSH може да работи и дори nginx може да е инсталиран. Въпреки това публичните уеб портове все още могат да нямат полезен слушател.

Първо проверете слушателите:

sudo ss -ltnp

Празен изход за :80 или :443 означава, че нищо полезно не слуша там. Слушател на 127.0.0.1 означава, че услугата приема връзки само от локалната машина. Слушател на 0.0.0.0 означава, че е свързан на IPv4 интерфейси. [::] обикновено означава IPv6 интерфейси. Не предполагайте, че IPv6 свързване автоматично гарантира IPv4 пътя, който ви трябва.

След това използвайте малък nginx здравен пакет преди да промените нещо:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Ако systemctl казва active (running), това само доказва, че процесът на услугата съществува
• nginx -t ви казва дали конфигурацията е валидна
• journalctl показва дали скорошното презареждане е неудачно, липсва файл с сертификат или vhost е счупен при стартиране.

За читатели на Apache, еквивалентния синтаксис за проверка е apachectl configtest. След като знаете, че нещо слуша, следващото доказателство е по-специфично: отговаря ли правилния сайт локално, когато премахнете външната мрежа от уравнението?

💡 Съвет: Първо тествайте конфигурацията, след това предпочетете reload вместо сляпо рестартиране, когато е подходящо. Презареждането валидира новата конфигурация и запазва старите работници, ако новата конфигурация е лоша; сляпото рестартиране е много по-грубо в средата на инцидент.

Стъпка 4: Тестване на сайта локално с правилния хост и SNI

Това е най-важното разклонение в цялото разследване. Обикновен curl 127.0.0.1 може да бъде подвеждащ. Много сървъри хостват множество сайтове и избират отговора въз основа на Host заглавката или, за HTTPS, SNI. Вие не питате дали нещо отговаря локално. Вие питате дали правилният път на сайта отговаря локално.

Използвайте локални тестове, които запазват логиката на хоста:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Смисленият успех е очакваната страница, очаквано пренасочване или очакван отговор на приложението от правилния сайт. Това не е хостът по подразбиране на nginx, неправилния сертификат или генеричен “той върна HTML.” От тук има три чисти резултата: локален успех, локално поведение на грешния сайт или сертификат по подразбиране, или локален отказ/timeout. Добрия локален резултат сочи навън към проверки на firewall, доставчик, CDN или маршрутизиране. Лош локален резултат ви держи вътре в стека, в клоновете upstream или TLS.

Стъпка 5: Ако работи локално, но не и външно, проследете мрежовия път

Когато локалният тест е успешен, спрете да се съмнявате в nginx за момент. Стекът на сайта вероятно е активен на сървъра, а липсващото звено обикновено е някъде между посетителя и работещата локална услуга. Започнете с хост файъла, защото това е най-близката външна граница, която контролирате.

Проверете правилата на хост страната с инструмента, който вашата система действително използва, и направете една бърза проверка на здравия разум за самонанесено блокиране, докато сте там:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Този резултат показва само слоя на гостната ОС. Той не показва филтриране на страната на доставчика, групи за сигурност или правила за файъл на панела, които живеят извън самия VPS. На AlexHost VPS, например, машинният файъл и всички контроли на мрежата на панела са отделни въпроси. И двете имат значение, когато локалните тестове работят, но публичните посетители все още не успяват.

⚠️ Внимание: Ако Docker публикува портове на хоста, не приемайте, че резултатът от UFW разказва цялата история. Docker може да маршрутизира публикуван трафик на контейнер чрез NAT преди обичайните вериги на UFW. Това означава, че “UFW изглежда добре” не винаги означава, че пътят на пакета е добър.

CDN и балансьори на натоварване заслужават собен клон тук. Произходът може да е здрав и все още недостъпен директно, защото само диапазоните на ръба могат да говорят с него. Когато имате нужда от доказателство дали пакетите изобщо пристигат, използвайте tcpdump като инструмент да/не:

📝 Забележка: Неуспешен тест на преки произход зад CDN списък обикновено сочи към политиката на ръба, а не към мъртвия произход. В тази конфигурация произходът е проектиран да доверява пътя на CDN, а не на всеки преки посетител.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Ако не видите никакви SYN пакети, трафикът не достига сървъра. Ако SYN пристигнат и няма SYN-ACK напускане, сървърът или пътят на файъла все още блокира предаването. Ако нито един модел не изглежда да е блокер, останалите отказания обикновено седят зад фронтенда при предаването нагоре по течението.

Стъпка 6: Ако Frontend отговаря, но сайтът все още е счупен, следвайте Upstream

В този клон уеб сървърът е достъпен, но следващия скок зад него не е достатъчно здрав, за да завърши заявката. Тук “upstream” означава услугата, към която nginx предава заявката: процес на приложение, runtime поддържан от сокет, контейнер или друга вътрешна зависимост.

Статичните страници работят, докато логване, търсене, плащане или API маршрути се провалят е силна улика, че frontend е налице и отказът започва при предаването зад него.

📝 Забележка: Третирайте 502 като “следващия скок отговори лошо” и 504 като “следващия скок отговори твърде бавно.” И двете са знаци да следите upstream пътя, а не да спирате на frontend.

Проверете активното предаване, след това тествайте upstream директно:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

В nginx изхода потърсете директиви като proxy_pass, fastcgi_pass или uwsgi_pass. Проверявате дали nginx сочи към правилната цел, по правилния протокол, на правилния порт или сокет. Ако са включени контейнери, добавете кратка проверка на здравето на контейнера вместо да гадаете:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Ако преките тест на приложението се провали, проблемът е зад уеб сървъра. Ако работи директно, но се провалява през nginx, конфигурацията на предаването е клонът за проверка. Достъпността на базата данни има значение само като проверка на зависимостта тук, а не като отделно дълбоко потапяне. Ако този модел на upstream отказ продължава да се повтаря, това е правилният момент да преминете към специализирано ръководство за отстраняване на неизправности, вместо да разтегляте един инцидент в гадаене.

Стъпка 7: Изолиране на TLS и неправилности на сертификатите

Този клон е по-тесен: нещо отговаря на 443, но браузърът все още не може да завърши чиста, надеждна HTTPS сесия. Успешна TCP връзка към порт 443 не доказва, че сертификатът, съответствието на хостнейма или пътят на handshake е здрав.

Проверете кой сертификат всъщност се предоставя:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

Тук хващате често срещаните форми на неправилности: грешен хостнейм, изтекъл сертификат, непълна верига или обновяване, което никога не завърши чисто. На обикновен език, SNI казва на сървъра кой хостнейм имахте предвид. -verify_hostname проверява дали сертификатът, който той предостави, съответства на този хостнейм. След възстановяване, валидирайте пътят на обновяване, така че това да не стане следващото прекъсване:

⚠️ Предупреждение: Ако разчитате на HTTP-01 валидация за обновяване на сертификат, входящият порт 80 трябва да бъде достъпен. Firewall или правило на доставчика, блокиращо 80, може тихо да счупи обновяванията много преди потребителите да докладват, че HTTPS изглежда мъртво.

sudo certbot renew --dry-run

Стъпка 8: Проверете натиска на ресурсите, преди да го наречете случайно

Някои инциденти изобщо не са отказ на достъпност. Пътят е технически интактен, но сървърът е твърде гладуван, блокиран или претоварен, за да отговори навреме. Това е когато сайтът може да изглежда “частично жив” от един ъгъл и все още да се чувства мъртъв за потребителите.

Изпълнете малък пакет за първи преглед на ресурсите:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Прочетете резултатите в модели, а не изолирано.

• df -h показва обичайното изчерпване на диска.
• df -i хваща изчерпването на inode, където пространството изглежда съществува, но файловата система не може да създаде повече записи.
• free -h е най-важно, когато наличната памет се срива и активността на swap се повишава.
• uptime може да покаже висок товар дори когато CPU не е максимално натоварен, което често означава, че задачите чакат натиск на диска или памет, а не активно изчисление.
• Редовете на ядрото на логовете за OOM събития ви казват дали системата е започнала да убива процеси, за да оцелее.

Графиките на доставчика могат да потвърдят времевата линия. На AlexHost VPS те могат да бъдат полезни за проверка дали скоковете в RAM, диск или I/O съвпадат с прекъсването. Но доказателствата от терминала все още трябва да водят диагнозата. Този раздел не е ръководство за настройка; това е клонът, който ви казва, че сайтът може да се проваля под натиск, а не да не маршрутизира.

Мислете в слоеве, не в паника

Когато SSH работи, но уебсайтът не се отваря, держите веригата кратка и повторяема:

1. възпроизведете отказа външно
2. идентифицирайте последния успешен етап
3. потвърдете DNS и дестинацията
4. проверете реален слушател на 80/443
5. тестирайте правилния сайт локално
6. разклонете се в пътя на мрежата, upstream, TLS или ресурси

💡 Съвет: Не затваряйте последната работеща SSH сесия, докато не потвърдите, че свежо влизане все още работи и все още имате резервен път за достъп, като достъп до конзолата на доставчика. По време на живо инцидент, запазването на контрол е толкова важно, колкото и поправката на първия симптом.

Держите навиците лесни: наблюдавайте външно, водете логове и тестирайте сертификати с certbot renew –dry-run. Защитете достъпа с резервни копия и пътека на конзолата. Инструментите на доставчика — firewall, графики, конзола (включително AlexHost) — трябва да поддържат отстраняването на неизправности, а не да го заменят. Фокусирайте се на поправката на първия счупен слой, така че всеки инцидент да се обработва с по-ясни доказателства и по-малко паника.