Jak działa serwer twojej strony i kogo wołać, gdy przestanie

Serwer to program, który przyjmuje żądania od przeglądarek i odsyła odpowiedzi - nie skrzynka w serwerowni. Zanim wybierzesz hosting albo VPS, ustal dwie rzeczy: co twoja strona faktycznie musi robić i kto wstaje, gdy przestanie działać. Ta strona porządkuje obie decyzje i prowadzi dalej.

Znajdziesz tu drogę, jaką przechodzi każde żądanie, podział odpowiedzialności między ludzi i firmy oraz mapę wyboru dalszej ścieżki: typy hostingu i ich zastosowania, własny serwer VPS albo diagnostykę, gdy strona nie działa.

Co właściwie jest serwerem twojej strony?

Serwer w znaczeniu, które ma znaczenie dla twojej strony, to program przyjmujący połączenia, obsługujący żądania i wysyłający odpowiedzi. Fizyczna maszyna tylko go uruchamia. Gdy hostingodawca pisze „serwer działa", ma na myśli maszynę - a twoja strona może w tym samym momencie zwracać błąd, bo zawiódł jeden z programów po drodze.

Tych programów bywa kilka i każdy gra inną rolę. Origin server tworzy właściwą odpowiedź dla zasobu - to on „ma" twoją stronę. Proxy pośredniczy w połączeniu po stronie klienta. Reverse proxy stoi na wejściu: dla przeglądarki wygląda jak serwer docelowy, a w rzeczywistości przekazuje żądanie dalej, do aplikacji. Jedno wejście na stronę potrafi przejść przez wszystkie trzy.

Z tego wynika praktyczna reguła: komunikat błędu w przeglądarce nie mówi ci jeszcze, który program zawiódł. Zanim zaczniesz naprawiać albo zgłaszać, nazwij warstwę - a jak to zrobić, pokazuje dalsza część tej strony.

Trzy osoby, trzy różne „serwery"

Renata prowadzi sklep internetowy z częściami do ekspresów. W piątek po południu klienci zaczynają dzwonić, że strona nie działa. Renata pisze do wykonawcy, który sklep zbudował - ten odpisuje, że wszystko działa, i wysyła na dowód zrzut ekranu z otwartym sklepem. Renata otwiera zgłoszenie u hostingodawcy - support odpowiada, że „serwer działa poprawnie, obciążenie w normie". Obaj mają rację i sklep dalej nie działa.

Wykonawca sprawdził proces aplikacji - działał. Hostingodawca sprawdził maszynę - działała. Zawiódł certyfikat na warstwie wejściowej, którego nikt nie odnowił, bo przy wdrożeniu nikt nie zapisał, że to czyjeś zadanie. Klienci z nowszych przeglądarek widzieli błąd, wykonawca z zapamiętanym wyjątkiem bezpieczeństwa - działającą stronę.

Ta historia jest fikcyjna, ale awaria w niej typowa: każda ze stron patrzyła na inną warstwę i każda swoją warstwę uczciwie potwierdziła. Żeby taka rozmowa nie trwała trzech dni, musisz wiedzieć, z jakich warstw składa się droga żądania - i kto odpowiada za każdą z nich.

Jaką drogę przechodzi żądanie, zanim klient zobaczy stronę?

Każde wejście na stronę przechodzi tę samą sekwencję. Gdy coś nie działa, awaria siedzi w jednym z tych punktów:

1. DNS zamienia nazwę domeny na adres. Jeśli ten krok zawiedzie, przeglądarka nie wie, dokąd się łączyć.
2. Przeglądarka nawiązuje połączenie z uzyskanym adresem. Odmowa na tym etapie znaczy, że nic po drugiej stronie nie słucha - albo zapora blokuje port.
3. Przy HTTPS negocjowany jest TLS - szyfrowanie, które chroni transmisję przed podsłuchem i podmianą. Wygasły certyfikat zatrzymuje wejście właśnie tutaj, jeszcze przed jakąkolwiek treścią.
4. Warstwa wejściowa przyjmuje żądanie. Jeśli to reverse proxy, przekazuje je do właściwej aplikacji.
5. Proces aplikacji buduje odpowiedź. Proces może działać, a mimo to zwracać błąd dla konkretnego żądania - to dwie różne rzeczy.
6. Odpowiedź wraca tą samą drogą do przeglądarki, a każdy element po drodze zapisuje zdarzenie w swoim logu.

Przy wdrożeniu zapisz dla każdego punktu nazwę usługi i osobę, która ma do niej dostęp. Nie potrzebujesz katalogu całej infrastruktury - potrzebujesz możliwości zadania konkretnego pytania konkretnej osobie: czy domena wskazuje właściwy adres, czy połączenie dochodzi, czy TLS się dogaduje, czy żądanie trafia do aplikacji i czy aplikacja odpowiada.

Kto za co odpowiada?

W utrzymaniu strony występują trzy role i granice między nimi ustalasz przed wdrożeniem, nie w trakcie awarii:

1. Ty albo osoba biznesowa - określacie, co strona ma robić, i podejmujecie decyzję o zmianie środowiska, gdy przestaje wystarczać.
2. Administrator albo wykonawca - utrzymuje powierzony zakres: aktualizacje, konfigurację, reakcję na zgłoszenia.
3. Dostawca środowiska - odpowiada za to, co zapisano w usłudze, i za nic więcej.

Jedna osoba może łączyć role, ale każda czynność potrzebuje jawnego właściciela z imienia i nazwiska. Certyfikat Renaty wygasł nie dlatego, że ktoś zawalił - tylko dlatego, że odnowienie nie było niczyim zadaniem. Sam wybór hostingu czy VPS-a niczego tu nie przesądza: brak przypisanej osoby jest dziurą organizacyjną w każdym środowisku.

Spisz to w czterech wierszach: kto aktualizuje, kto patrzy w logi, kto reaguje na awarię, kto decyduje o przeprowadzce. Jeśli przy którymś wierszu nie umiesz wpisać osoby, decyzja o zakupie jest przedwczesna.

Hosting czy VPS - jak wybrać?

Hosting oznacza środowisko zarządzane: dostawca utrzymuje system, a ty dostajesz panel i ustalony zakres kontroli. VPS oznacza własny serwer wirtualny: pełna kontrola nad systemem, ale też pełna odpowiedzialność za aktualizacje, kopie i reakcję na awarie - twoja albo opłaconego administratora.

Za kontrolę VPS-a płacisz obowiązkami, nie tylko rachunkiem. Jeśli nikt w firmie nie będzie systemu aktualizował i czytał jego logów, większa kontrola oznacza w praktyce serwer, którym nikt się nie zajmuje. Dla strony, która mieści się w zakresie zwykłej usługi, wybieramy hosting - po VPS sięgnij wtedy, gdy aplikacja wymaga rzeczy, których panel hostingu nie da, i masz nazwaną osobę do administracji.

Szczegóły obu dróg opisujemy osobno: typy hostingu i granice ich zastosowań oraz prowadzenie własnego środowiska na VPS.

Gdzie szukać dalej - mapa tego działu

Ta strona daje mapę; szczegółowe odpowiedzi mieszkają w tekstach obok. Wybierz wiersz pasujący do twojej sytuacji:

Tabelę czytaj od lewej - najpierw nazwij sytuację, potem sprawdź, czy masz dostęp i osobę do danej warstwy, na końcu przejdź do tekstu. Jeśli nie umiesz wskazać osoby, wróć do sekcji o odpowiedzialności - to tam jest twój pierwszy problem, nie w wyborze produktu.

Co sprawdzić przed uruchomieniem strony?

Przed publikacją przejdź listę punkt po punkcie - każdy warunek weryfikujesz osobno, bo potwierdzenie jednego nie dowodzi pozostałych:

1. Domena wskazuje adres usługi, do której klient ma trafić.
2. Połączenie dochodzi do warstwy wejściowej na właściwym porcie.
3. Certyfikat działa, a jego odnowienie ma przypisaną osobę albo automat, którego ktoś pilnuje.
4. Warstwa wejściowa wie, dokąd przekazać żądanie - w nginx ustawia to dyrektywa proxy_pass.
5. Proces aplikacji działa i odpowiada na testowe żądanie.
6. Logi każdej warstwy zapisują się tam, gdzie osoba diagnozująca ma dostęp.
7. Awaria ma przypisaną osobę reagującą, nie tylko adres do zgłoszeń.

Działający proces nie mówi nic o DNS ani certyfikacie, a poprawnie rozwiązująca się domena nie potwierdza odpowiedzi aplikacji. Wynik każdego testu ma zakres równy testowanemu elementowi - dlatego lista ma siedem punktów, a nie jeden „czy strona działa".

Jak ustalić, która warstwa zawiodła?

Zacznij od objawu widocznego u klienta i przypisz go do etapu drogi żądania. Komunikat o nieznalezionej domenie prowadzi do DNS, a pierwszym odczytem jest wtedy zapytanie do serwera nazw przez nslookup. Odmowa połączenia prowadzi do warstwy wejściowej i zapory. Błąd przed pojawieniem się jakiejkolwiek treści, z ostrzeżeniem o bezpieczeństwie, wskazuje na TLS. Odpowiedź z kodem od bramy - jak 502 czy 504 - każe sprawdzić relację między warstwą wejściową a aplikacją. Błąd w treści strony należy już do samej aplikacji.

Nie naprawiaj kilku warstw naraz. Zmiana DNS, certyfikatu i konfiguracji wejścia jednym ruchem usuwa punkt odniesienia - nie dowiesz się, co pomogło ani co zepsuło resztę. Nazwij etap, zbierz komunikat i log z elementu, który odpowiedział, i dopiero wtedy działaj.

Konkretne kody i komunikaty rozbieramy w diagnostyce błędów, a problemy z HTTPS w tekście o certyfikatach. Osiągalność maszyny i jakość trasy sieciowej sprawdzisz poleceniem ping. Polecenia do sprawdzenia usług, logów i certyfikatów zbiera dział komend administracyjnych, a samo logowanie na zdalną maszynę przez SSH ma osobną procedurę - od pierwszego połączenia po diagnozę odmowy.

Pytania o serwer strony i aplikacji

Co to jest serwer strony internetowej?

Serwer strony internetowej to program, który przyjmuje połączenia od przeglądarek, obsługuje żądania i wysyła odpowiedzi. Fizyczna maszyna tylko go uruchamia. W drodze jednego żądania może uczestniczyć kilka takich programów - reverse proxy na wejściu i proces aplikacji za nim - dlatego diagnoza awarii zaczyna się od wskazania, który z nich odpowiedział.

Czy strona firmowa potrzebuje własnego serwera?

Nie, dopóki mieści się w zakresie usługi zarządzanej. Strona wizytówkowa, blog i niewielki sklep pracują na hostingu, gdzie systemem zajmuje się dostawca. Własne środowisko na VPS ma sens dopiero, gdy aplikacja wymaga rzeczy niedostępnych w panelu hostingu - i gdy masz nazwaną osobę, która będzie ten system aktualizować i pilnować.

Czym różni się hosting od VPS-a?

Na hostingu dostawca utrzymuje system operacyjny, a ty pracujesz w udostępnionym zakresie - panelu, plikach, bazie. Na VPS-ie dostajesz cały system i wszystkie obowiązki: aktualizacje, kopie zapasowe, reakcję na awarie. Różnicę mierz potrzebną kontrolą i tym, kto będzie administrował, nie ceną z pierwszej strony cennika.

Kto odpowiada za serwer strony firmowej?

Odpowiadają trzy strony naraz - ty jako właściciel decydujesz o kierunku, administrator albo wykonawca utrzymuje powierzony zakres, a dostawca odpowiada za to, co zapisano w usłudze. Kłopot zaczyna się tam, gdzie czynność - jak odnowienie certyfikatu - nie jest niczyim zadaniem. Rozpisz obowiązki na osoby przed uruchomieniem, nie podczas pierwszej awarii.

Od czego zacząć, gdy strona nie działa?

Od objawu, nie od restartowania wszystkiego. Ustal, co dokładnie widzi klient: brak domeny wskazuje DNS, odmowa połączenia warstwę wejściową, ostrzeżenie o bezpieczeństwie certyfikat, a kod 502 lub 504 relację między wejściem a aplikacją. Z nazwanym etapem przejdź do naszej diagnostyki błędów - tam objawy są rozpisane na konkretne kroki.

Źródła

Role serwera, proxy i bramy definiuje RFC 9110 w sekcjach 3.3, 3.6 i 3.7. Rozwiązywanie nazw domenowych opisuje RFC 1034 w sekcjach 2.3 i 3, a użycie TLS w HTTP - RFC 9846. Działanie SSH dokumentują strony podręcznika OpenBSD, ssh(1). Przekazywanie żądań przez nginx opisuje dokumentacja modułu ngx_http_proxy_module, dyrektywa proxy_pass.