Kategoria: ISPConfig

WordPress i błąd „A scheduled event has failed”?
Każdy administrator strony na WordPressie zna to uczucie. Logujesz się do panelu, a tam czeka na Ciebie komunikat: „A scheduled event has failed”. Serce na chwilę staje. Czy strona padła? Czy to poważna awaria?
Spokojnie! Zanim zaczniesz panikować, weź głęboki oddech. Ten błąd, choć brzmi poważnie, rzadko oznacza katastrofę. Najczęściej jest to po prostu sygnał, że wewnętrzny mechanizm harmonogramu zadań w WordPressie nie działa optymalnie.
W tym artykule wyjaśnimy, czym jest ten błąd, dlaczego się pojawia i jak go profesjonalnie naprawić w różnych konfiguracjach serwerowych.
Czym jest WP-Cron?
WordPress musi wykonywać cykliczne zadania w tle: publikować zaplanowane posty, tworzyć kopie zapasowe czy skanować witrynę w poszukiwaniu wirusów (jak w przypadku błędu wf_scan_monitor od wtyczki Wordfence). Do obsługi tych operacji używa wbudowanego mechanizmu o nazwie WP-Cron.
Problem polega na tym, że WP-Cron nie jest prawdziwym demonem cron znanym z systemów uniksowych. To „pseudo-cron”, który ma fundamentalną wadę: uruchamia się tylko wtedy, gdy ktoś odwiedzi Twoją stronę internetową.
- Na stronach o małym ruchu: Jeśli nikt nie wchodzi na witrynę, zadania nie są wykonywane o czasie, co prowadzi do błędów.
- Na stronach o dużym ruchu: WP-Cron jest wywoływany przy każdym załadowaniu strony, co generuje niepotrzebne obciążenie serwera.
W obu przypadkach rozwiązanie jest takie samo: wyłączyć wbudowany WP-Cron i zastąpić go stabilnym, systemowym zadaniem cron.
Scenariusz 1: Pojedyncza strona WordPress
To podstawowa i najczęstsza konfiguracja. Rozwiązanie problemu jest proste i sprowadza się do dwóch kroków.
Krok 1: Wyłącz wbudowany mechanizm WP-Cron
Edytuj plik wp-config.php w głównym katalogu swojej strony i dodaj poniższą linię:
```
define('DISABLE_WP_CRON', true);
```
Krok 2: Skonfiguruj systemowy cron
Zaloguj się do swojego serwera przez SSH i wpisz crontab -e, aby edytować listę zadań systemowych. Następnie dodaj jedną z poniższych linii, która co 5 minut będzie wywoływać mechanizm crona WordPressa we właściwy sposób.
- Metoda z wget:*/5 * * * * wget -q -O - https://twojadomena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1
- Metoda z curl:*/5 * * * * curl -s https://twojadomena.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Pamiętaj, aby podmienić twojadomena.pl na właściwy adres. Od teraz zadania będą wykonywane regularnie, niezależnie od ruchu na stronie.
Scenariusz 2: Wiele stron na standardowym serwerze
Jeśli zarządzasz wieloma stronami, dodawanie osobnej linii w crontab dla każdej z nich jest niepraktyczne i trudne w utrzymaniu. Lepszym rozwiązaniem jest stworzenie jednego skryptu, który automatycznie znajdzie wszystkie instalacje WordPressa i uruchomi dla nich zadania.
Krok 1: Stwórz plik skryptu
Utwórz plik, np. /usr/local/bin/run_all_wp_crons.sh, i wklej do niego poniższą zawartość. Skrypt przeszukuje katalog /var/www/ w poszukiwaniu plików wp-config.php.
```
#!/bin/bash

# =================================================================
# Skrypt do uruchamiania zadań cron dla wszystkich stron WordPress
# Zoptymalizowany dla struktury katalogów ISPConfig
# =================================================================

# Główny katalog, w którym znajdują się FAKTYCZNE pliki stron w ISPConfig
SITES_ROOT="/var/www/clients/"

# Ścieżka do interpretera PHP (może wymagać dostosowania)
PHP_EXECUTABLE="/usr/bin/php"

# Logowanie (opcjonalne, ale przydatne do debugowania)
LOG_FILE="/var/log/wp_cron_runner.log"
echo "Rozpoczynam uruchamianie zadań cron (ISPConfig): $(date)" >> $LOG_FILE

# Znajdź wszystkie pliki wp-config.php i uruchom dla nich wp-cron.php
find "$SITES_ROOT" -name "wp-config.php" -print0 | while IFS= read -r -d '' config_file; do

    # Wyodrębnij katalog, w którym znajduje się WordPress
    WP_DIR=$(dirname "$config_file")

    # Wyodrębnij nazwę użytkownika (np. web4) z ścieżki
    # Jest to siódmy element w ścieżce /var/www/clients/client4/web4/web/
    WP_USER=$(echo "$WP_DIR" | awk -F'/' '{print $6}')

    if [ -z "$WP_USER" ]; then
        echo "-> OSTRZEŻENIE: Nie udało się określić użytkownika dla: $WP_DIR" >> $LOG_FILE
        continue
    fi

    # Sprawdź, czy plik wp-cron.php istnieje w tym katalogu
    if [ -f "$WP_DIR/wp-cron.php" ]; then
        echo "-> Uruchamiam cron dla: $WP_DIR jako użytkownik: $WP_USER" >> $LOG_FILE
        # Uruchom wp-cron.php używając PHP CLI, przełączając się na właściwego użytkownika
        su -s /bin/sh "$WP_USER" -c "(cd '$WP_DIR' && '$PHP_EXECUTABLE' wp-cron.php)"
    else
        echo "-> OSTRZEŻENIE: Znaleziono wp-config, ale brak wp-cron.php w: $WP_DIR" >> $LOG_FILE
    fi

done

echo "Zakończono: $(date)" >> $LOG_FILE
echo "---" >> $LOG_FILE
```
Krok 2: Nadaj skryptowi uprawnienia do wykonania
```
chmod +x /usr/local/bin/run_all_wp_crons.sh
```
Krok 3: Stwórz jedno zadanie cron do zarządzania wszystkim
Teraz Twój crontab -e może zawierać tylko jedną linię:
```
*/5 * * * * /usr/local/bin/run_all_wp_crons.sh >/dev/null 2>&1
```
Scenariusz 3: Wiele stron z panelem ISPConfig
Panel ISPConfig używa specyficznej struktury katalogów z dowiązaniami symbolicznymi (symlinkami), np. /var/www/twojadomena.pl wskazuje na /var/www/clients/client1/web1/. Użycie powyższego skryptu mogłoby spowodować podwójne wykonanie zadań.
Aby tego uniknąć, należy zmodyfikować skrypt tak, by przeszukiwał tylko docelowy katalog clients.
Krok 1: Stwórz skrypt zoptymalizowany dla ISPConfig
Utwórz plik /usr/local/bin/run_ispconfig_crons.sh. Zwróć uwagę na zmianę w zmiennej SITES_ROOT.
```
#!/bin/bash

# Skrypt do uruchamiania zadań cron dla wszystkich stron WordPress
# Zoptymalizowany dla struktury katalogów ISPConfig

# Przeszukujemy tylko katalog z faktycznymi plikami stron
SITES_ROOT="/var/www/clients/"

# Ścieżka do interpretera PHP
PHP_EXECUTABLE="/usr/bin/php"

# Opcjonalny plik logu do śledzenia postępów
LOG_FILE="/var/log/wp_cron_runner.log"
echo "Rozpoczynam uruchamianie zadań cron (ISPConfig): $(date)" >> $LOG_FILE

find "$SITES_ROOT" -name "wp-config.php" -print0 | while IFS= read -r -d '' config_file; do
    
    WP_DIR=$(dirname "$config_file")

    if [ -f "$WP_DIR/wp-cron.php" ]; then
        echo "-> Uruchamiam cron dla: $WP_DIR" >> $LOG_FILE
        (cd "$WP_DIR" && "$PHP_EXECUTABLE" wp-cron.php)
    fi

done

echo "Zakończono: $(date)" >> $LOG_FILE
echo "---" >> $LOG_FILE
```
Krok 2 i 3 są analogiczne jak w scenariuszu 2: nadaj skryptowi uprawnienia (chmod +x) i dodaj jedną linię do crontab -e, wskazując na nowy plik skryptu.
Podsumowanie
Błąd „A scheduled event has failed” to nie powód do paniki, a raczej zaproszenie do ulepszenia swojej infrastruktury. To szansa, by przejść z zawodnego, wbudowanego mechanizmu WordPressa na solidne, profesjonalne rozwiązanie systemowe, które gwarantuje stabilność i wydajność.
Niezależnie od konfiguracji serwera, teraz masz narzędzia, by spać spokojnie, wiedząc, że Twoje zaplanowane zadania wykonują się jak w szwajcarskim zegarku.
25 lipca, 2025

OpenLiteSpeed (OLS) z Redis. Szybka pamięć Cache dla stron WordPress.

Zarządzanie serwerem WWW wymaga zrozumienia komponentów, które składają się na jego architekturę. Każdy element odgrywa kluczową rolę w dostarczaniu treści użytkownikom w sposób szybki i niezawodny. Ten artykuł stanowi dogłębną analizę nowoczesnej konfiguracji serwerowej opartej na OpenLiteSpeed (OLS), wyjaśniając jego podstawowe mechanizmy, współpracę z systemem buforowania Redis oraz metody komunikacji z aplikacjami zewnętrznymi.

Sekcja 1: OpenLiteSpeed (OLS) – Rdzeń Systemu

Fundamentem każdej witryny jest serwer WWW – oprogramowanie odpowiedzialne za przyjmowanie żądań HTTP od przeglądarek i zwracanie im odpowiednich zasobów, takich jak pliki HTML, CSS, JavaScript czy obrazy.

Czym jest OpenLiteSpeed?

OpenLiteSpeed (OLS) to wysokowydajny, lekki serwer WWW o otwartym kodzie źródłowym, rozwijany przez LiteSpeed Technologies. Jego kluczową przewagą nad tradycyjnymi serwerami, takimi jak Apache w domyślnej konfiguracji, jest architektura sterowana zdarzeniami (event-driven).

Model procesowy (np. Apache prefork): Dla każdego jednoczesnego połączenia tworzony jest oddzielny proces lub wątek. Model ten jest prosty, ale przy dużym ruchu prowadzi do znacznego zużycia pamięci RAM i zasobów procesora, ponieważ każdy proces, nawet nieaktywny, rezerwuje zasoby.
Model sterowany zdarzeniami (OpenLiteSpeed, Nginx): Jeden proces roboczy serwera jest w stanie obsługiwać setki lub tysiące połączeń jednocześnie. Wykorzystuje on nieblokujące operacje wejścia/wyjścia (non-blocking I/O) i pętlę zdarzeń (event loop) do zarządzania żądaniami. Gdy proces czeka na operację (np. odczyt z dysku), nie blokuje się, lecz przechodzi do obsługi innego połączenia. Taka architektura zapewnia znacznie lepszą skalowalność i mniejsze zużycie zasobów.

Kluczowe Funkcje OpenLiteSpeed

OLS oferuje zestaw funkcji, które czynią go potężnym i elastycznym narzędziem:

Graficzny Interfejs Administracyjny (WebAdmin GUI): OLS posiada wbudowany panel administracyjny dostępny przez przeglądarkę, który umożliwia konfigurację wszystkich aspektów serwera – od wirtualnych hostów, przez ustawienia PHP, po reguły bezpieczeństwa – bez konieczności bezpośredniej edycji plików konfiguracyjnych.
Wbudowany Moduł Buforujący (LSCache): Jedną z najważniejszych funkcji OLS jest LSCache, zaawansowany i wysoce konfigurowalny mechanizm buforowania pełnych stron (full-page cache). W połączeniu z dedykowanymi wtyczkami dla systemów CMS (np. WordPress), LSCache przechowuje w pamięci w pełni wyrenderowane strony HTML. Gdy nadchodzi kolejne żądanie o tę samą stronę, serwer dostarcza ją bezpośrednio z bufora, całkowicie omijając wykonanie kodu PHP i zapytania do bazy danych.
Wsparcie dla Nowoczesnych Protokołów (HTTP/3): OLS natywnie wspiera najnowsze protokoły sieciowe, w tym HTTP/3 (oparty na QUIC). Zapewnia to mniejsze opóźnienia i lepszą wydajność, zwłaszcza na niestabilnych połączeniach mobilnych.
Kompatybilność z Regułami Apache: OLS potrafi interpretować dyrektywy mod_rewrite z plików .htaccess, co jest standardem w ekosystemie Apache. Upraszcza to znacząco proces migracji istniejących aplikacji bez konieczności przepisywania złożonych reguł przepisywania adresów URL.

Sekcja 2: Redis – Akcelerator Danych w Pamięci Operacyjnej

Buforowanie (caching) to fundamentalna technika optymalizacyjna, polegająca na przechowywaniu wyników kosztownych operacji w szybszym medium dostępowym. W kontekście aplikacji webowych, Redis jest jednym z najpopularniejszych narzędzi do realizacji tego zadania.

Czym jest Redis?

Redis (REmote DIctionary Server) to działająca w pamięci operacyjnej (in-memory) struktura danych, używana najczęściej jako baza danych typu klucz-wartość, bufor lub broker wiadomości. Jego potęga wynika z faktu, że wszystkie dane przechowuje w pamięci RAM, a nie na dysku twardym. Dostęp do RAM jest o rzędy wielkości szybszy niż dostęp do dysków SSD czy HDD, ponieważ jest to operacja czysto elektroniczna, omijająca wolniejsze interfejsy I/O.

W typowej aplikacji webowej Redis pełni rolę bufora obiektów (object cache). Przechowuje on wyniki zapytań do bazy danych, fragmenty wyrenderowanego kodu HTML lub złożone obiekty PHP, które są kosztowne do ponownego wygenerowania.

Jak Działa Współpraca OpenLiteSpeed i Redis?

Mechanizmy buforowania LSCache i Redis nie wykluczają się, lecz doskonale uzupełniają, tworząc wielowarstwową strategię optymalizacji.

Przepływ żądania (uproszczony):

Użytkownik wysyła żądanie o dynamiczną stronę (np. wpis na blogu).
OpenLiteSpeed odbiera żądanie. Pierwszym krokiem jest sprawdzenie bufora LSCache.
- TRAFIENIE w LSCache (Cache Hit): Jeśli w LSCache znajduje się aktualna, w pełni wyrenderowana wersja strony, OLS natychmiast ją zwraca. Proces kończy się w tym miejscu. Jest to najszybszy możliwy scenariusz.
- BRAK w LSCache (Cache Miss): Jeśli strony nie ma w buforze, OLS przekazuje żądanie do odpowiedniej aplikacji zewnętrznej (np. interpretera PHP) w celu jej wygenerowania.
Aplikacja PHP rozpoczyna budowanie strony. Aby to zrobić, musi pobrać dane z bazy danych (np. MySQL).
Zanim PHP wykona kosztowne zapytania do bazy danych, najpierw sprawdza bufor obiektów w Redis.
- TRAFIENIE w Redis: Jeśli potrzebne dane (np. wyniki zapytań SQL) znajdują się w Redis, są one zwracane natychmiast. PHP używa tych danych do zbudowania strony, omijając komunikację z bazą danych.
- BRAK w Redis: Jeśli danych nie ma w buforze, PHP wykonuje zapytania do bazy danych, pobiera wyniki, a następnie zapisuje je w Redis na potrzeby przyszłych żądań.
PHP kończy generowanie strony HTML i zwraca ją do OpenLiteSpeed.
OLS wysyła stronę do użytkownika, a jednocześnie zapisuje ją w buforze LSCache, aby kolejne żądania mogły być obsłużone znacznie szybciej.

Ta dwuwarstwowa strategia zapewnia, że zarówno pierwsze, jak i kolejne odwiedziny strony są maksymalnie zoptymalizowane. LSCache eliminuje potrzebę uruchamiania PHP, a Redis drastycznie przyspiesza sam proces generowania strony, gdy jest to konieczne.

Sekcja 3: Delegowanie Zadań – Aplikacje Zewnętrzne w OLS

Nowoczesne serwery WWW są zoptymalizowane do obsługi połączeń sieciowych i dostarczania plików statycznych (obrazy, CSS). Wykonywanie kodu aplikacji (treści dynamicznej) jest delegowane do wyspecjalizowanych programów zewnętrznych. Taki podział obowiązków zwiększa stabilność i bezpieczeństwo.

OpenLiteSpeed zarządza tymi programami poprzez system Aplikacji Zewnętrznych. Poniżej opisano najważniejsze typy:

Aplikacja LSAPI (LiteSpeed SAPI App): Najbardziej wydajna i zalecana metoda komunikacji z aplikacjami PHP, Python czy Ruby. LSAPI to autorski, zoptymalizowany protokół, który minimalizuje narzut komunikacyjny między serwerem a interpreterem aplikacji.
Aplikacja FastCGI: Bardziej uniwersalny, standardowy protokół do komunikacji z zewnętrznymi procesami aplikacji. Jest to dobre rozwiązanie dla aplikacji, które nie wspierają LSAPI. Działa na podobnej zasadzie co LSAPI (utrzymując stałe procesy robocze), ale z nieco większym narzutem protokołu.
Serwer WWW (Proxy): Ten typ konfiguruje OLS do działania jako odwrotne proxy (reverse proxy). OLS przyjmuje żądanie od klienta, a następnie przekazuje je w całości do innego serwera działającego w tle (tzw. backend), np. serwera aplikacji napisanego w Node.js, Javie czy Go. Jest to kluczowe do budowania architektur opartych na mikroserwisach.
Aplikacja CGI: Historyczna i najwolniejsza metoda. Dla każdego żądania uruchamiany jest nowy proces aplikacji, który jest zamykany po zwróceniu odpowiedzi. Ze względu na ogromny narzut wydajnościowy, jest używana tylko dla starszych aplikacji, które nie wspierają nowszych protokołów.

OLS kieruje ruch do odpowiedniej aplikacji za pomocą Obsługi Skryptów (Script Handlers), która mapuje rozszerzenia plików (np. .php) na konkretną aplikację, lub Kontekstów (Contexts), które mapują ścieżki URL (np. /api/) na aplikację typu proxy.

Sekcja 4: Język Komunikacji – Porównanie Architektur SAPI

SAPI (Server Application Programming Interface) to interfejs definiujący, w jaki sposób serwer WWW komunikuje się z interpreterem aplikacji (np. PHP). Wybór implementacji SAPI ma fundamentalny wpływ na wydajność i stabilność całego systemu.

Ewolucja SAPI

CGI (Common Gateway Interface): Pierwszy standard. Stabilny, ale niewydajny z powodu uruchamiania nowego procesu dla każdego żądania.
Moduł wbudowany (np. mod_php w Apache): Interpreter PHP jest ładowany bezpośrednio do procesu serwera. Zapewnia to bardzo szybką komunikację, ale kosztem stabilności (awaria PHP powoduje awarię serwera) i bezpieczeństwa.
FastCGI: Kompromis między wydajnością a stabilnością. Utrzymuje pulę niezależnych, długo działających procesów PHP, co eliminuje koszt ich ciągłego uruchamiania. Komunikacja odbywa się przez gniazdo, co zapewnia izolację od serwera WWW.
LSAPI (LiteSpeed SAPI): Ewolucja modelu FastCGI. Wykorzystuje tę samą architekturę z oddzielnymi procesami, ale sam protokół komunikacyjny został zaprojektowany od podstaw w celu minimalizacji narzutu, co przekłada się na jeszcze wyższą wydajność niż w przypadku standardowego FastCGI.

Tabela Porównawcza Architektur SAPI

Cecha	CGI	Moduł Wbudowany (mod_php)	FastCGI	LiteSpeed SAPI (LSAPI)
Model Procesu	Nowy proces na żądanie	Współdzielony proces z serwerem	Stałe procesy zewnętrzne	Stałe procesy zewnętrzne
Wydajność	Niska	Bardzo wysoka	Wysoka	Najwyższa
Stabilność / Izolacja	Doskonała	Niska	Wysoka	Wysoka
Zużycie Zasobów	Bardzo wysokie	Umiarkowane	Niskie	Bardzo niskie
Narzut Komunikacyjny	Wysoki (uruchamianie procesu)	Minimalny (wspólna pamięć)	Umiarkowany (protokół)	Niski (zoptymalizowany protokół)
Główna Zaleta	Pełna izolacja	Szybkość komunikacji	Zrównoważona wydajność i stabilność	Zoptymalizowana wydajność i stabilność
Główna Wada	Bardzo niska wydajność	Niestabilność, problemy z bezpieczeństwem	Bardziej złożona konfiguracja	Technologia specyficzna dla LiteSpeed

Porównanie Gniazd Komunikacyjnych

Komunikacja między procesami (np. OLS a Redis, lub OLS a procesy PHP) odbywa się za pośrednictwem gniazd (sockets). Wybór typu gniazda ma wpływ na wydajność.

Cecha	Gniazdo TCP/IP (na localhost)	Gniazdo Domeny Uniksowej (UDS)
Adresowanie	Adres IP + Port (np. `127.0.0.1:6379`)	Ścieżka pliku (np. `/var/run/redis.sock`)
Zasięg	Ta sama maszyna lub przez sieć	Tylko ta sama maszyna (IPC)
Wydajność (lokalnie)	Niższa	Wyższa
Narzut (Overhead)	Wyższy (przechodzi przez stos sieciowy)	Minimalny (omija stos sieciowy)
Model Bezpieczeństwa	Reguły zapory sieciowej (firewall)	Uprawnienia systemu plików

W przypadku komunikacji lokalnej, UDS jest rozwiązaniem wydajniejszym, ponieważ omija cały stos sieciowy systemu operacyjnego, co redukuje opóźnienia i narzut procesora. Dlatego w zoptymalizowanych konfiguracjach jest preferowany do połączeń między OLS, Redis i procesami LSAPI.

Sekcja 5: Praktyczna Implementacja i Zarządzanie

Aby przełożyć teorię na praktykę, przeanalizujmy rzeczywistą konfigurację serwera dla wirtualnego hosta solutionsinc.co.uk .

5.1 Analiza Konfiguracji na Przykładzie `solutionsinc.co.uk`

Definicja Aplikacji Zewnętrznej (External App):
- W panelu „External App” zdefiniowano aplikację typu LiteSpeed SAPI App o nazwie solutionsinc.co.uk. Jest to centralny punkt konfiguracji dla dynamicznej obsługi strony.
- Adres (Address): UDS://tmp/lshttpd/solutionsinc.co.uk.sock. Ta linia jest kluczowa. Informuje OLS, że do komunikacji z aplikacją PHP będzie używane Gniazdo Domeny Uniksowej (UDS), a nie gniazdo sieciowe TCP/IP. Plik .sock pod tą ścieżką jest fizycznym punktem końcowym tego wydajnego kanału komunikacji.
- Polecenie (Command): /usr/local/lsws/lsphp84/bin/lsphp. To jest bezpośrednia ścieżka do pliku wykonywalnego interpretera LiteSpeed PHP w wersji 8.4. OLS wie, że ma uruchomić ten właśnie program do przetwarzania skryptów.
- Pozostałe parametry, jak LSAPI_CHILDREN=50 czy limity pamięci, służą do precyzyjnego zarządzania zasobami i wydajnością puli procesów PHP.
Powiązanie z Plikami PHP (Script Handler):
- Sama definicja aplikacji nie wystarczy. W panelu „Script Handler” mówimy OLS, kiedy ma jej używać.
- Dla sufiksu (rozszerzenia) php ustawiono obsługę przez LiteSpeed SAPI.
- Jako Handler Name wybrano [VHost Level]: solutionsinc.co.uk, co bezpośrednio wskazuje na aplikację zdefiniowaną w poprzednim kroku.
- Wniosek: Od tej pory każde żądanie pliku z rozszerzeniem .php na tej stronie zostanie przekazane przez gniazdo UDS do jednego z procesów lsphp84.

Ta konfiguracja jest doskonałym przykładem zoptymalizowanego i bezpiecznego środowiska: OLS obsługuje połączenia, a dedykowane, odizolowane procesy lsphp84 wykonują kod aplikacji, komunikując się przez najszybszy dostępny kanał – gniazdo domeny uniksowej.

5.2 Zarządzanie Gniazdami Domeny Uniksowej (`.sock`) i Rozwiązywanie Problemów

Plik .sock, jak widać w przykładzie solutionsinc.co.uk.sock, nie jest zwykłym plikiem. Jest to specjalny plik w systemach uniksowych, który działa jako punkt końcowy dla komunikacji międzyprocesowej (IPC). Zamiast komunikować się przez warstwę sieciową (nawet lokalną), procesy mogą zapisywać i odczytywać dane bezpośrednio z tego pliku, co jest znacznie szybsze.

Kiedy OpenLiteSpeed uruchamia aplikację zewnętrzną LSAPI, tworzy taki plik gniazda. Procesy PHP nasłuchują na tym gnieździe na przychodzące żądania od OLS.

Praktyczna porada: „Uparty” plik .sock

Czasami po wprowadzeniu zmian w konfiguracji PHP (np. modyfikacji pliku php.ini lub instalacji nowego rozszerzenia) i restarcie serwera OpenLiteSpeed (lsws), zmiany mogą nie być widoczne na stronie. Dzieje się tak, ponieważ procesy lsphp mogły nie zostać poprawnie zrestartowane wraz z serwerem, a OLS wciąż komunikuje się ze starymi procesami przez istniejący, „stary” plik .sock.

W takiej sytuacji, gdy standardowy restart nie pomaga, skutecznym rozwiązaniem jest:

Zatrzymać serwer OpenLiteSpeed.
Ręcznie usunąć odpowiedni plik .sock, np. za pomocą polecenia w terminalu:rm /tmp/lshttpd/solutionsinc.co.uk.sock
Ponownie uruchomić serwer OpenLiteSpeed.

Po ponownym uruchomieniu OLS, nie znajdując istniejącego pliku gniazda, zostanie zmuszony do stworzenia go na nowo. Co ważniejsze, uruchomi przy tym nową pulę procesów lsphp, które wczytają świeżą konfigurację z pliku php.ini. Usunięcie pliku .sock działa jak twardy reset kanału komunikacyjnego między serwerem a aplikacją PHP, gwarantując, że wszystkie komponenty zostaną zainicjowane od zera z aktualnymi ustawieniami.

Sekcja 6: Podsumowanie

Przedstawiona konfiguracja serwera to precyzyjnie zaprojektowany system, w którym każdy element odgrywa istotną rolę.

OpenLiteSpeed działa jako wydajny, sterowany zdarzeniami rdzeń, zarządzający połączeniami.
LSCache zapewnia błyskawiczne dostarczanie stron z bufora pełnej strony.
Redis działa jako bufor obiektów, drastycznie przyspieszając generowanie treści dynamicznych, gdy jest to potrzebne.
LSAPI i UDS tworzą zoptymalizowane kanały komunikacyjne, minimalizując narzut i opóźnienia.

Zrozumienie tych zależności pozwala na świadome zarządzanie serwerem i jego optymalizację w celu osiągnięcia maksymalnej wydajności i niezawodności.

25 lipca, 2025

Ubuntu Server 24.04 + ISPConfig (Nginx) + OpenLiteSpeed: Nowoczesny i Wydajny Serwer WWW i Email bez CyberPanel
Wstęp
Witajcie, drodzy administratorzy serwerów, zapaleńcy linuksowych rozwiązań i wszyscy ci, którzy na hasło „reverse proxy” nie wybiegają z pokoju z krzykiem. Dziś podzielę się z Wami historią migracji, która – niczym dobre sci-fi – ma swoje zwroty akcji, niespodzianki i happy end (a przynajmniej na razie!).
Przez ostatnie lata moim głównym narzędziem do zarządzania serwerem WWW i pocztą był zestaw OpenLiteSpeed z CyberPanel. Jednak życie (a konkretnie: autorzy CyberPanel) postanowili, że Ubuntu 24.04 LTS nie będzie im w głowie. I tak przez ponad 3 lata… Aktualizacja? Zapomnij! Support dla nowych wersji Ubuntu? Pomyliłeś adres! Tak oto w czerwcu 2025 roku, mimo licznych próśb i oczekiwań, CyberPanel wciąż nie wspiera najnowszego Ubuntu. I nie zapowiada się, by coś się w tej kwestii zmieniło.
Ale nie ma tego złego… Postanowiłem więc wziąć sprawy w swoje ręce. W efekcie powstała hybryda na miarę XXI wieku: Ubuntu Server 24.04, ISPConfig z Nginx jako reverse proxy oraz OpenLiteSpeed bez CyberPanelowego balastu. Dlaczego taka kombinacja? Bo lubię mieć kontrolę, cenię sobie wydajność, elastyczność i – co tu kryć – nie chcę być zakładnikiem archaicznych paneli admina.
Takie rozwiązanie daje:
- Świeżutki, wspierany system operacyjny z długim wsparciem (a nie wykopaliska z 2022 roku)
- Pełną kontrolę nad konfiguracją, bez ograniczeń narzucanych przez CyberPanel
- Możliwość korzystania z wydajności OpenLiteSpeed i prostoty zarządzania przez ISPConfig
- Bezproblemową obsługę zarówno stron WWW, jak i poczty (a kto próbował skonfigurować własną pocztę na OLS + CyberPanel ten wie, jak wygląda piekło)
- Nowoczesność, elastyczność i gotowość na przyszłość – a przy okazji mniej siwych włosów na głowie
Czy jest to rozwiązanie dla każdego? Pewnie nie – ale jeśli masz dość czekania na łaskę twórców panelu, szukasz czegoś wydajnego i lubisz mieć nad wszystkim kontrolę – zostań ze mną. W kolejnych częściach pokażę, jak skonfigurować taki serwer krok po kroku, bez zbędnych zaklęć i frustracji.
Dlaczego warto tworzyć osobnych klientów dla każdej strony w ISPConfig?
Konfigurując serwer w ISPConfig, bezpieczeństwo i porządek to podstawa. Dlatego jedną z najlepszych praktyk jest tworzenie osobnego klienta dla każdej strony internetowej, którą zamierzamy hostować. Takie podejście nie tylko upraszcza zarządzanie, ale przede wszystkim podnosi poziom bezpieczeństwa – nawet jeśli na pierwszy rzut oka wydaje się to bardziej czasochłonne.
Zalety zakładania osobnego klienta dla każdej strony:
1. Izolacja danych – Każdy klient (a więc i jego strony, maile, bazy danych) działa w swojej własnej „piaskownicy”. Gdyby doszło do włamania na jedną stronę, pozostałe są dużo lepiej chronione.
2. Łatwiejsza administracja – Zarządzanie uprawnieniami, kopie zapasowe, limity zasobów – wszystko jest czytelne i można ustawiać indywidualnie dla każdego klienta.
3. Przejrzystość rozliczeń – Jeśli świadczysz usługi hostingowe, łatwiej rozliczysz się z każdym klientem osobno.
4. Bezpieczna poczta – Konta e-mail klientów są od siebie oddzielone. Spam lub włamanie do jednego konta nie wpływa na pozostałe.
5. Prostsze przenosiny lub usuwanie – Usunięcie jednej strony (razem z klientem) nie wpłynie na inne witryny na serwerze.
Pokażę teraz, jak – krok po kroku – stworzyć klienta pod nową stronę na przykładzie solutionsinc.co.uk.
Limity i bezpieczeństwo w ISPConfig – dlaczego to takie ważne?
Po utworzeniu klienta w ISPConfig, jednym z najważniejszych etapów konfiguracji jest ustawienie limitów oraz zadbanie o bezpieczeństwo konta. Dzięki ISPConfig możesz precyzyjnie określić, ile zasobów (stron, kont e-mail, baz danych itp.) może wykorzystać każdy klient – to świetne narzędzie do zarządzania zarówno komercyjnymi usługami hostingowymi, jak i własnymi projektami.
Przykładowe limity, które możesz ustawić:
- Maksymalna liczba domen i subdomen
- Limit przestrzeni dyskowej (Web Quota)
- Limit transferu (Traffic Quota)
- Liczba kont FTP, użytkowników SSH
- Możliwość korzystania z określonych technologii (np. PHP, Python, Ruby, SSL, Let’s Encrypt)
- Limity dla e-maili, baz danych, zadań Cron i innych usług
Ustawianie limitów pozwala utrzymać porządek, zapobiega przypadkowemu „przeciążeniu” serwera i chroni przed nadużyciami (np. przez błędną konfigurację aplikacji lub atak DDoS).
Bezpieczne hasło – Twój pierwszy mur obronny
Bardzo istotną sprawą podczas tworzenia konta klienta jest ustawienie silnego, długiego hasła – najlepiej losowego, wygenerowanego przez manager haseł. Proponuję wybrać hasło o długości nawet 64 znaków, składające się z małych i wielkich liter, cyfr oraz znaków specjalnych. Dzięki managerowi haseł nie musisz go pamiętać, a Twoje konto jest znacznie bezpieczniejsze przed atakami.
Pamiętaj: Słabe, powtarzalne lub krótkie hasła to zaproszenie dla cyberprzestępców!
Opis opcji sekcji „Web Limits” w ISPConfig
- Webservers: Serwer WWW, na którym będą zakładane strony klienta. Zazwyczaj do wyboru masz zdefiniowane wcześniej serwery w panelu.
- Max. number of web domains: Maksymalna liczba domen, które klient może dodać. Wartość -1 oznacza brak limitu.
- Web Quota: Limit przestrzeni dyskowej na pliki stron WWW klienta (w MB). -1 = bez limitu.
- Traffic Quota: Limit miesięcznego transferu danych (w MB) dla wszystkich stron klienta. -1 = brak limitu.
- PHP Options: Możesz włączyć/wyłączyć PHP oraz wybrać tryb działania (np. PHP-FPM, Disabled). Ważne dla bezpieczeństwa i wydajności.
- CGI available: Czy klient może uruchamiać skrypty CGI (zazwyczaj wyłączone ze względów bezpieczeństwa).
- SSI available: Pozwala na używanie Server Side Includes.
- Perl available / Ruby available / Python available: Dostępność tych języków dla stron klienta.
- SuEXEC forced: Wymusza uruchamianie skryptów z uprawnieniami użytkownika domeny, zwiększa bezpieczeństwo.
- Custom error docs available: Czy można definiować własne strony błędów (np. 404.html).
- Wildcard subdomain available: Umożliwia obsługę subdomen typu *.twojadomena.pl.
- SSL available: Czy klient może aktywować SSL na swoich stronach (https).
- Let’s Encrypt available: Umożliwia generowanie darmowych certyfikatów SSL Let’s Encrypt dla stron klienta.
- Max. number of web aliasdomains: Maksymalna liczba domen aliasów (np. dodatkowe domeny wskazujące na tę samą stronę).
- Max. number of web subdomains: Maksymalna liczba subdomen na stronach klienta.
- Max. number of FTP users: Limit liczby użytkowników FTP dla klienta.
- Max. number of Shell users: Liczba użytkowników z dostępem do SSH (zazwyczaj 0 dla bezpieczeństwa).
- SSH-Chroot Options: Określa, czy użytkownicy SSH są ograniczeni (chroot) do swojego katalogu domowego („Jailkit”).
- Max. number of Webdav users: Limit liczby użytkowników WebDAV.
- Backupfunction available: Czy klient może wykonywać własne kopie zapasowe z poziomu panelu.
- Show web server config selection: Pozwala klientowi wybierać dodatkowe opcje konfiguracji serwera WWW (dla zaawansowanych).
Opis opcji sekcji „Email Limits” w ISPConfig
- Mailservers: Serwer poczty, na którym obsługiwane będą skrzynki i domeny pocztowe klienta.
- Max. number of email domains: Maksymalna liczba domen e-mail, które może utworzyć klient (-1 = bez limitu).
- Max. number of mailboxes: Maksymalna liczba skrzynek pocztowych dla klienta (-1 = bez limitu).
- Max. number of email aliases: Limit aliasów e-mail (np. dodatkowych adresów przekierowujących do skrzynki).
- Max. number of domain aliases: Liczba aliasów domeny e-mail (czyli dodatkowych domen przypisanych do tej samej poczty).
- Max. number of mailing lists: Limit list mailingowych (grupowa wysyłka wiadomości).
- Max. number of email forwarders: Maksymalna liczba przekierowań e-mail (forwardów).
- Max. number of email catchall accounts: Liczba kont „catchall”, odbierających wszystkie wiadomości wysyłane na nieistniejące adresy w domenie.
- Max. number of email routes: Liczba tras routingu e-maili (zaawansowane – przekierowywanie poczty na inne serwery według reguł).
- Max. number of email white / blacklist entries: Maksymalna liczba pozycji na białej/czarnej liście dla danego klienta.
- Max. number of email filters: Limit filtrów e-mail (np. do automatycznego sortowania lub oznaczania poczty).
- Max. number of fetchmail accounts: Liczba zewnętrznych kont (fetchmail) – pobieranie poczty z innych serwerów.
- Mailbox quota: Limit rozmiaru skrzynki pocztowej (w MB). -1 = bez limitu.
- Max. number of spamfilter white / blacklist filters: Liczba reguł białej/czarnej listy w filtrze antyspamowym.
- Max. number of spamfilter users: Liczba użytkowników mających własne ustawienia antyspamu.
- Max. number of spamfilter policies: Liczba polityk (zestawów reguł) antyspamowych.
- E-mail backup function available: Czy klient może samodzielnie tworzyć kopie zapasowe poczty przez panel.
Tworzenie użytkownika bazy danych dla strony – ISPConfig
Po utworzeniu klienta i ustaleniu limitów, kolejnym krokiem jest stworzenie osobnego użytkownika bazy danych dla nowej strony (np. solutionsinc.co.uk). W tym celu przechodzimy do zakładki Sites, a następnie do sekcji zarządzania bazami danych.
1. Wybierz klienta z listy (np. SolutionsInc).
2. Wprowadź nazwę użytkownika bazy danych – ISPConfig automatycznie sugeruje prefiks powiązany z klientem (np. c2_). Dzięki temu każdy użytkownik jest unikalny i łatwy do zidentyfikowania.
3. Ustaw hasło do bazy danych. Skorzystaj z przycisku Generate Password i wybierz długie, losowe hasło (najlepiej przechowywane w menedżerze haseł). Silne hasło to podstawa bezpieczeństwa, nawet jeśli nie musisz go zapamiętywać.
4. Powtórz hasło w polu „Repeat Password”.
5. Kliknij Save, aby utworzyć użytkownika.
Tworzenie oddzielnych użytkowników do każdej strony to ważny krok – jeśli dojdzie do wycieku hasła, atak ogranicza się tylko do jednej bazy. Dzięki temu nawet poważny błąd w aplikacji nie daje napastnikowi dostępu do innych danych na serwerze.
Opis opcji zakładki „Domain” przy tworzeniu strony WWW w ISPConfig
- Server: Serwer WWW, na którym będzie hostowana domena. Wybierz odpowiedni serwer z listy dostępnych.
- Client: Klient, do którego przypisana będzie ta domena/strona.
- IPv4-Address: Adres IPv4 przypisany do tej domeny (domyślnie *, czyli dowolny dostępny IP na serwerze).
- IPv6-Address: Adres IPv6, jeśli jest używany (opcjonalnie).
- Domain: Nazwa domeny, którą chcesz dodać (np. solutionsinc.co.uk).
- Harddisk Quota: Limit przestrzeni dyskowej dla tej konkretnej strony (w MB). -1 oznacza brak limitu.
- Traffic Quota: Limit transferu danych dla tej strony (w MB miesięcznie). -1 oznacza brak limitu.
- CGI: Czy zezwolić na uruchamianie skryptów CGI na stronie (zazwyczaj wyłączone dla bezpieczeństwa).
- SSI: Czy włączyć obsługę Server Side Includes.
- Own Error-Documents: Pozwala na ustawianie własnych stron błędów (np. 404.html).
- Auto-Subdomain: Domyślna subdomena, która zostanie automatycznie dodana (najczęściej www).
- SSL: Zaznacz jeśli posiadasz własny certyfikat SSL i chcesz ręcznie wgrać certyfikaty do panelu.
- Let’s Encrypt SSL: Wybierz tę opcję, jeśli chcesz, aby ISPConfig automatycznie wygenerował darmowy certyfikat SSL Let’s Encrypt dla tej domeny (nie musisz posiadać własnych certyfikatów).
- PHP: Wybierz tryb działania PHP dla strony. Jeśli zamierzasz używać Nginx jako Reverse Proxy dla OpenLiteSpeed, wybierz koniecznie PHP-FPM oraz dokładnie tę wersję PHP, na której działa OLS. Pozostałe tryby (np. Disabled) nie będą poprawnie współpracować z takim rozwiązaniem.
- Web server config: Dodatkowe opcje konfiguracyjne serwera WWW (zaawansowane, można zostawić domyślnie).
- Active: Czy strona ma być aktywna (zaznaczona domyślnie – strona po zapisaniu będzie działać).
Opis opcji zakładki „Redirect” w ISPConfig (Reverse Proxy)
- Redirect Type: Określa rodzaj przekierowania dla danej domeny. Jeśli chcesz skonfigurować Nginx jako reverse proxy dla OpenLiteSpeed, koniecznie ustaw tutaj opcję proxy. Dzięki temu ruch HTTP/S będzie przekazywany do właściwego backendu (OLS).
- Redirect Path: Adres docelowy (URL/backend), do którego ma być przekazywany ruch. W przypadku reverse proxy wpisz tutaj adres backendu (np. http://127.0.0.1:8088/ – pamiętaj, żeby nie używać portu 8080, ponieważ jest on zajęty przez ISPConfig!).
- SEO Redirect: Opcjonalne przekierowania SEO (np. 301, 302, non-www→www). Najczęściej pozostawiamy jako „No redirect”, chyba że masz specyficzne wymagania SEO.
- Rewrite Rules: Pole na własne reguły rewrite, zgodne z modułem nginx_http_rewrite_module. Możesz tu dodawać dodatkowe instrukcje modyfikujące ruch HTTP, np. break, if, return, rewrite, set (pełna lista na stronie nginx).
- Rewrite HTTP to HTTPS: Po zaznaczeniu automatycznie przekierowuje cały ruch z HTTP na HTTPS. Zalecane przy stronach wymagających SSL.
Uwaga: Pamiętaj, że w przypadku konfiguracji reverse proxy kluczowe jest ustawienie Redirect Type na proxy i prawidłowe podanie backendu w Redirect Path.
Zakładka SSL w ISPConfig – co tutaj ustawić?
- Jeśli w zakładce Domain zaznaczyłeś opcję Let’s Encrypt SSL, nie musisz tutaj nic wypełniać. Certyfikat zostanie wygenerowany automatycznie i pola pozostaną puste.
- Jeśli korzystasz z własnych certyfikatów SSL, wklej je odpowiednio do poniższych pól:
  - SSL Key: Klucz prywatny (private key)
  - SSL Request: Żądanie podpisania certyfikatu (CSR) – opcjonalne, jeśli go używasz
  - SSL Certificate: Właściwy certyfikat SSL (publiczny)
  - SSL Bundle: Certyfikaty pośrednie/CA Bundle (jeśli wymaga tego Twój dostawca SSL)
- SSL Domain: Domena, dla której generowany/instalowany jest certyfikat (wypełnia się automatycznie)
- SSL Action: Domyślnie „Save certificate” – zachowuje wprowadzone dane
Wskazówka: Jeśli zmieniasz typ certyfikatu (np. przechodzisz z własnego certyfikatu na Let’s Encrypt lub odwrotnie), pamiętaj, by odznaczyć zbędne opcje w zakładce Domain i zapisać zmiany.
Zakładka Statistics w ISPConfig – własne statystyki dla Twojej strony
Jeśli chcesz mieć niezależny system statystyk strony (poza tym, co oferuje np. WordPress czy Google Analytics), ta zakładka jest dla Ciebie. Tutaj możesz skonfigurować, jaki program będzie generował i prezentował szczegółowe statystyki ruchu na Twojej stronie. Oto krótkie opisy dostępnych opcji:
- AWStats: Najpopularniejszy program do generowania szczegółowych statystyk www. Analizuje logi serwera i prezentuje czytelne wykresy, podsumowania ruchu, popularność stron, źródła odwiedzin, wyszukiwane frazy i inne dane. Interfejs webowy, obsługa wielu języków.
- GoAccess: Nowoczesny analizator logów działający w czasie rzeczywistym, także z interfejsem webowym. Bardzo szybki, daje czytelne podsumowania najważniejszych danych (unikalni użytkownicy, najpopularniejsze strony, kody błędów itp.). Może być bardziej „techniczny” od AWStats.
- Webalizer: Starszy, ale bardzo lekki i szybki program do analizy logów. Prezentuje podstawowe statystyki ruchu, wykresy godzinowe/dniowe, listę najczęściej odwiedzanych stron, ale z mniejszą ilością szczegółów niż AWStats.
- None: Brak statystyk. Przydatne jeśli korzystasz wyłącznie z zewnętrznych rozwiązań lub chcesz ograniczyć zużycie zasobów.
Wskazówka: Pamiętaj, by ustawić hasło do panelu statystyk, jeśli chcesz, by dostęp był chroniony!
Zakładka Backup – Twoja sieć bezpieczeństwa (i spokój ducha)
W tej zakładce możesz ustawić automatyczne kopie zapasowe strony i bazy danych lub wykonać backup ręcznie, gdy tylko masz na to ochotę (albo poczujesz przypływ zdrowego rozsądku).
Dostępne opcje:
- Backup interval: Jak często wykonywać kopie (np. codziennie, co tydzień, co miesiąc, lub wcale – nie polecam tej ostatniej opcji!).
- Number of backup copies: Ile ostatnich backupów przechowywać na serwerze.
- Excluded Directories: Katalogi, które mają być pomijane w backupie (np. cache lub katalogi z danymi tymczasowymi).
- Compression options: Możesz skompresować swoje backupy, żeby nie zajmowały pół serwera – polecam!
- Encryption options: Możesz zaszyfrować kopie zapasowe – dzięki temu nawet jeśli backup trafi w niepowołane ręce, Twoje dane pozostaną bezpieczne.
Ręczny backup: Dwa magiczne przyciski – zrób backup bazy lub plików jednym kliknięciem.
Anegdota: Są dwa typy ludzi: ci, którzy robią backupy, i ci, którzy dopiero będą je robić po pierwszym poważnym krachu. Szkoda, że ta lekcja zawsze przychodzi za późno!
Zakładka Options – kluczowa dla Reverse Proxy (Nginx → OLS)
Jeśli używasz Nginx jako Reverse Proxy dla OpenLiteSpeed (lub innego backendu), koniecznie skonfiguruj odpowiednie nagłówki w polu Proxy Directives. Wklej tam poniższe linie:
```
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
```
Dlaczego to ważne?
- proxy_set_header Host $host;
  Przekazuje oryginalną nazwę hosta (domeny), pod jaką użytkownik wszedł na stronę. Dzięki temu backend (OLS) wie, dla jakiej domeny przetwarza żądanie i poprawnie rozpoznaje wirtualne hosty.
- proxy_set_header X-Real-IP $remote_addr;
  Przekazuje prawdziwy adres IP klienta, a nie adres serwera proxy. Dzięki temu w logach, statystykach oraz przy mechanizmach bezpieczeństwa widoczny jest rzeczywisty użytkownik.
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  Dodaje oryginalny adres IP klienta do specjalnego nagłówka X-Forwarded-For. Przydatne jeśli ruch przechodzi przez kilka proxy – można odtworzyć całą „trasę” zapytania.
- proxy_set_header X-Forwarded-Proto $scheme;
  Informuje backend, czy oryginalne żądanie było po HTTPS czy HTTP. Dzięki temu aplikacje mogą generować poprawne linki zwrotne (np. z https:// zamiast http://).
Podsumowanie:
Bez tych nagłówków backend (OLS) nie będzie wiedział, kto naprawdę odwiedza Twoją stronę, pod jaką domeną, i czy używa HTTPS. Skutki mogą być poważne: błędne logi, niepoprawne generowanie linków, problemy z SSL, a nawet luki w bezpieczeństwie.
Ostatni krok: konfiguracja OpenLiteSpeed pod Reverse Proxy
Gdy wszystkie ustawienia po stronie ISPConfig są gotowe, przechodzimy do panelu OpenLiteSpeed, który znajdziesz pod adresem http://IP_SERWERA:7080.
Co robimy:
1. Przechodzimy do sekcji Listeners.
2. Usuwamy wszystkie listenery poza Listener Default na porcie 8088 (to na nim OLS będzie „słuchał” żądań od Nginx Reverse Proxy).
3. Klikamy w ikonkę lupki przy naszym Listenerze i przechodzimy do sekcji Virtual Host Mappings.
4. Dodajemy mapping dla naszej strony, np. solutionsinc.co.uk (lub innej, którą podajesz w ISPConfig).
Dlaczego tak?
- Zarządzaniem SSL (wystawianiem, odnawianiem, przekierowaniami itp.) zajmuje się teraz Nginx wraz z ISPConfig, więc nie trzeba już konfigurować SSL w OLS.
- Pozostałe zakładki listenery mogą zostać bez zmian – cała magia dzieje się teraz po stronie reverse proxy.
Podsumowanie:
Od tej pory Nginx przejmuje na siebie cały ruch (w tym HTTPS), a do OLS przekazuje już czyste żądania na lokalnym porcie (8088). To idealne połączenie wydajności, wygody i bezpieczeństwa.
Virtual Hosts > Basic w OpenLiteSpeed – jak poprawnie uzupełnić?
1. Virtual Host Name: Nazwa hosta wirtualnego – wpisz nazwę domeny, np. solutionsinc.co.uk.
2. Virtual Host Root: Wpisz tu dokładnie taki adres, jak w polu Document Root w ISPConfig (np. /var/www/clients/client1/web1/), pamiętając o końcowym slashem /. Dzięki temu OLS będzie serwował pliki z właściwej lokalizacji.
3. Config File: Wpisz bashKopiujEdytuj$SERVER_ROOT/conf/vhosts/$VH_NAME/vhost.conf Podczas próby zapisu OLS zgłosi, że taki plik nie istnieje – kliknij wtedy w link pod polem, aby ten plik utworzyć automatycznie. Po tej operacji będzie można zapisać ustawienia bez błędów.
4. suEXEC User i suEXEC Group:
  Wybierz tutaj dokładnie tego użytkownika i grupę, jakie ISPConfig utworzył dla Twojej domeny. Możesz to sprawdzić w ISPConfig w zakładce Sites > Website > Options.
  To bardzo ważne – pozwala OLS uruchamiać skrypty PHP z prawidłowymi uprawnieniami, poprawia bezpieczeństwo i chroni przed dostępem do plików innych użytkowników.
5. External App Set UID Mode: Wybierz opcję DocRoot UID. Dzięki temu zewnętrzne aplikacje (np. PHP) będą uruchamiane jako użytkownik powiązany z katalogiem domeny.
6. W sekcji Security znajdują się opcje kluczowe dla bezpieczeństwa i poprawnego działania hosta wirtualnego. Każdą z tych opcji ustaw na Yes:
  - Follow Symbolic Link:
    Pozwala OLS na podążanie za linkami symbolicznymi w katalogu strony. Jest to wymagane np. przez niektóre aplikacje, frameworki lub podczas aktualizacji oprogramowania.
  - Enable Scripts/ExtApps:
    Umożliwia uruchamianie skryptów (np. PHP) oraz zewnętrznych aplikacji. Bez tej opcji Twoja strona nie będzie mogła przetwarzać PHP ani korzystać z dynamicznych funkcji.
  - Restrained:
    Włącza „tryb ograniczony” – zwiększa bezpieczeństwo, ograniczając możliwości wywoływania pewnych poleceń systemowych przez hosta wirtualnego.
  - Pamiętaj:
  - Ustawienie każdej z tych opcji na Yes jest niezbędne do poprawnej i bezpiecznej pracy Twojej strony przy współpracy z ISPConfig i reverse proxy.
Zakładka General – OpenLiteSpeed Virtual Host
Najważniejsze opcje:
- Document Root:
  Katalog, w którym znajduje się Twoja strona. Tu wklejasz ścieżkę z ISPConfig (Sites → Website → Document Root) i na końcu dodajesz katalog strony, zazwyczaj /web/, czyli np. /var/www/clients/client1/web1/web/. Zawsze sprawdzaj tę ścieżkę w ISPConfig, bo może się różnić!
Pozostałe opcje:
- Domain Name:
  (Opcjonalnie) Możesz wpisać główną domenę tego vhosta.
- Domain Aliases:
  Inne domeny, które mają wskazywać na tego vhosta (np. wersje z www i bez www).
- Administrator Email:
  E-mail administratora tej strony (przydatny do powiadomień o błędach).
- Enable GZIP Compression:
  Włącza kompresję GZIP na poziomie serwera – przyspiesza ładowanie strony.
- Enable Brotli Compression:
  Alternatywna metoda kompresji (jeszcze wydajniejsza niż GZIP).
- Enable GeoLocation Lookup:
  Pozwala serwerowi sprawdzać, z jakiego kraju pochodzi użytkownik (np. do statystyk).
- cgroups:
  Opcjonalne ograniczenia zasobów dla vhosta – jeśli chcesz limity CPU/RAM.
Sekcja Index Files:
- Use Server Index Files:
  Powinno być ustawione na „No”, aby OLS używał plików indeksowych zdefiniowanych poniżej, a nie globalnych z serwera.
- Index Files:
  Lista nazw plików, które mają być traktowane jako plik startowy strony (np. index.php, index.html). Jeśli oba istnieją, pierwszy z listy zostanie użyty.
- Auto Index:
  Pozwala na automatyczne generowanie indeksu katalogu, jeśli nie ma pliku index (zalecane „Not Set”/wyłączone ze względów bezpieczeństwa).
- Auto Index URI:
  Pozwala wskazać adres, pod którym wyświetli się automatyczny indeks katalogu.
Customized Error Pages:
- Tutaj możesz podać własne strony błędów (np. 404, 500).
Expires Settings:
- Enable Expires, Expires Default, Expires By Type:
  Kontrolują cache’owanie plików przez przeglądarki (możesz ustawić, jak długo przeglądarka ma trzymać pliki statyczne). Najczęściej zostawiamy domyślnie i konfigurujemy cache przez .htaccess lub w ustawieniach aplikacji.
File Upload:
- Temporary File Path, Temporary File Permission, Pass Upload Data by File Path:
  Zaawansowane ustawienia dot. przesyłania plików – gdzie zapisywane są pliki tymczasowe, jakie mają uprawnienia, i czy dane przesyłane są przez ścieżkę pliku (raczej zostaw domyślnie).
php.ini Override:
- Pozwala podać własne ustawienia PHP tylko dla tego vhosta – jeśli nie musisz zmieniać limitów (np. upload_max_filesize), zostaw puste.
Zakładka Log – niezależne logi dla każdej witryny
Dlaczego warto ustawić osobne logi?
- Izolacja: Osobne logi dla każdej strony ułatwiają zarządzanie, rozwiązywanie problemów oraz audyt – nie musisz szukać swojej witryny w jednym wielkim pliku wspólnym dla całego serwera.
- Bezpieczeństwo: Jeżeli masz kilka klientów lub projektów, osobne logi ograniczają dostęp tylko do niezbędnych danych i pomagają zachować porządek.
- Łatwiejsza analiza: Szybciej wykryjesz, co dzieje się na danej stronie, np. ataki, błędy, czy nieprawidłowe żądania.
Virtual Host Log (log błędów)
- Use Server’s Log:
  Jeśli ustawisz na „No”, logi błędów będą prowadzone oddzielnie dla tej strony. Zalecane, bo błędy konkretnej witryny nie zginą wśród błędów innych projektów.
- File Name:
  Ścieżka do pliku logu błędów tej strony (np. /var/www/clients/client1/solutionsinc.co.uk/log/error.log). Umieszczenie w katalogu domeny ułatwia zarządzanie backupem i dostępem.
- Log Level:
  Poziom szczegółowości logów (DEBUG, INFO, NOTICE, WARN, ERROR, CRIT).
  DEBUG to najwięcej szczegółów – przydatne przy debugowaniu, ale do codziennego działania wystarczy WARN lub ERROR.
- Rolling Size (bytes):
  Maksymalny rozmiar pliku logów, po przekroczeniu którego utworzony zostanie nowy plik (np. 10M). Chroni dysk przed zapchaniem.
- Keep Days:
  Ile dni przechowywać stare logi – przydatne do audytu lub cofania się do przeszłych incydentów.
- Compress Archive:
  Czy archiwizować i kompresować stare logi. Zalecane przy dużej liczbie logów, pozwala oszczędzić miejsce na dysku.
Access Log (log dostępu)
- Log Control:
  Wybierz „Own Log File”, by każdy vhost miał własny plik logu dostępu. Dzięki temu łatwiej analizować ruch na konkretnych stronach.
- File Name:
  Ścieżka do logu dostępu (np. /var/www/clients/client1/solutionsinc.co.uk/log/access_log).
- Piped Logger:
  Zaawansowana opcja – logi mogą być przetwarzane „w locie” przez zewnętrzne programy. Zostaw puste jeśli nie używasz.
- Log Format:
  Format pojedynczego wpisu logu – domyślna opcja sprawdza się w większości przypadków, ale możesz dostosować pod potrzeby analizy.
- Log Headers:
  Zaznacz „Referrer”, „UserAgent”, „Host” – dzięki temu logi będą zawierały kluczowe informacje o odwiedzających, źródłach wejść i typach urządzeń.
- Rolling Size (bytes):
  Jak duży może być pojedynczy plik logu, zanim zacznie się tworzyć kolejny (np. 50M).
- Keep Days:
  Ile dni przechowywać logi dostępu (np. 365 – pełen rok historii).
- Compress Archive:
  Warto ustawić na „Yes”, by stare logi były automatycznie kompresowane.
- Bytes log:
  Opcjonalnie: plik, w którym zapisywana jest statystyka przesłanych bajtów (raczej dla zaawansowanych analiz).
Zalecane ustawienia:
- Dla produkcji ustaw Log Level na WARN lub ERROR, a na czas uruchamiania i testów – DEBUG.
- Zawsze kompresuj archiwalne logi.
- Przechowuj logi co najmniej 30 dni – najlepiej 90 lub więcej, jeśli masz miejsce.
- Dla Access Log: zawsze osobny plik per domena, zawsze z Referrer, UserAgent i Host.
Zakładka Security – opis wszystkich opcji
Uwaga:
Nie musisz konfigurować tych ustawień, aby uruchomić stronę przez Nginx jako Reverse Proxy!
Jeśli nie masz doświadczenia z zaawansowaną ochroną i kontenerami – najlepiej najpierw uruchomić stronę, upewnić się że wszystko działa, a dopiero potem wracać tutaj i testować poszczególne opcje.
Sekcja: LS reCAPTCHA
- Enable reCAPTCHA, Site Key, Secret Key, reCAPTCHA Type, Max Tries, Concurrent Request Limit
  Pozwala aktywować mechanizmy reCAPTCHA (ochrona przed botami i atakami brute force na poziomie serwera). Trzeba podać klucze z Google oraz ustawić limity prób.
  Praktyka: Tylko dla osób, które dokładnie wiedzą jak to działa – błędna konfiguracja może zablokować ruch na stronie.
Sekcja: Containers
- Bubblewrap Container
  Pozwala uruchomić vhost w odizolowanym kontenerze z użyciem narzędzia Bubblewrap (większe bezpieczeństwo – aplikacje są „odcięte” od systemu).
  Zaawansowana funkcja – nie zalecane dla początkujących.
- Namespace Container, Additional Namespace Template File
  Umożliwiają izolację hosta w osobnej przestrzeni nazw (namespace), dodatkowo zwiększając bezpieczeństwo, ale wymagają wiedzy o konteneryzacji w Linuksie.
Sekcja: Access Control
- Allowed List
  Lista adresów IP, które mają mieć dostęp do tej strony.
- Denied List
  Lista adresów IP, które mają być zablokowane. Uwaga: Jeśli źle to skonfigurujesz, możesz nieświadomie zablokować dostęp do własnej strony!
Sekcja: Realm List
- Tutaj możesz skonfigurować „realm” – czyli strefy z własnym uwierzytelnianiem (np. ochrona katalogu hasłem na poziomie serwera).
Podsumowanie praktyczne
- Dla działania strony przez Nginx jako Reverse Proxy, NIE musisz nic tu ustawiać.
- Te opcje to narzędzia dla zaawansowanych administratorów – dla większości użytkowników najlepiej zostawić je domyślne, dopóki strona nie działa poprawnie.
- Zalecenie: Najpierw uruchom stronę, sprawdź poprawność, potem (opcjonalnie) wracaj do tej zakładki, jeśli chcesz podnieść poziom bezpieczeństwa.
Zakładka External App – opis i zalecenia
Ta zakładka odpowiada za powiązanie serwera www z interpreterem PHP, dzięki czemu twoje aplikacje PHP działają poprawnie.
Najważniejsze pola:
- Name:
  Nazwa aplikacji zewnętrznej, np. solutionsinc.co.uk. Może być dowolna, ale najlepiej ustawić nazwę zgodną z domeną dla porządku.
- Address:
  MUST HAVE!
  Gniazdo komunikacji z interpreterem PHP, np. UDS:///tmp/lshttpd/solutionsinc.co.uk.sock
  UDS (Unix Domain Socket) zawsze z dużej litery! Umożliwia szybszą i bezpieczniejszą komunikację niż połączenia sieciowe.
- Notes:
  Dowolny opis, jeśli potrzebujesz (opcjonalne).
- Max Connections:
  Maksymalna liczba równoczesnych połączeń do PHP. Zalecane 50, chyba że twoja strona obsługuje bardzo duży ruch – wtedy możesz zwiększyć.
- Environment:
  Dodatkowe zmienne środowiskowe. Przykład: LSAPI_CHILDREN=50 – ustala liczbę procesów potomnych PHP dla tej aplikacji.
- Initial Request Timeout (secs):
  Czas oczekiwania na odpowiedź przy pierwszym żądaniu (np. 600 sekund). Dłuższy czas jest bezpieczny przy wolniejszych serwerach lub długich skryptach.
- Retry Timeout (secs):
  Ile sekund serwer ma czekać i ponawiać próbę w przypadku błędu połączenia z PHP.
- Persistent Connection:
  Najlepiej zostawić „Yes” – pozwala na utrzymywanie otwartych połączeń i przyspiesza obsługę wielu żądań.
- Connection Keep-Alive Timeout:
  Jak długo (w sekundach) połączenie z PHP pozostaje otwarte po obsłużeniu żądania (domyślnie 1).
- Response Buffering:
  „No” oznacza natychmiastowe przekazywanie odpowiedzi do klienta. Zalecane dla stron dynamicznych.
- Start By Server:
  „Yes (Through CGI Daemon)” – serwer sam uruchamia proces PHP, co jest bezpieczniejsze i wygodniejsze.
- Command:
  KLUCZOWE!
  Ścieżka do interpretera PHP, np. /usr/local/lsws/lsphp83/bin/lsphp
  Upewnij się, że ten plik istnieje i jest to właściwa wersja PHP, której używasz. Jak sprawdzić:
  W konsoli serwera wpisz: bashKopiujEdytujls -l /usr/local/lsws/lsphp83/bin/lsphp Jeśli plik istnieje – ścieżka jest OK. Jeśli nie – sprawdź czy masz zainstalowaną wersję PHP 8.3 przez LiteSpeed (np. przez menadżer LiteSpeed lub polecenie lsphp).
- Back Log:
  Maksymalna liczba żądań oczekujących na połączenie z PHP (zalecane 100).
- Instances:
  Liczba instancji aplikacji (w praktyce: ilość niezależnych procesów). Zwykle 1 – jeśli nie masz bardzo wymagającej aplikacji.
- Run As User / Run As Group:
  Muszą odpowiadać użytkownikowi i grupie zdefiniowanym w ISPConfig dla tej strony (np. web1/client1). Dzięki temu każdy vhost działa z uprawnieniami przypisanymi tylko do własnych plików, co znacznie podnosi bezpieczeństwo.
- umask:
  Maska uprawnień dla tworzonych plików – najczęściej zostawiamy puste.
- Run On Start Up, Max Idle Time, Priority:
  Zaawansowane opcje – zwykle nie wymagają zmiany.
- Memory Soft Limit / Hard Limit:
  Miękki i twardy limit RAM dla procesu PHP (w bajtach).
  Zalecane: 2047M (2GB) – dostosuj do mocy serwera i potrzeb aplikacji.
- Process Soft Limit / Hard Limit:
  Ograniczenie liczby procesów (soft/hard).
  Soft – ostrzeżenie, hard – blokada. Przykład: Soft 400, Hard 500.
Zakładka Script Handler – do czego służy?
Ta sekcja decyduje, jakie aplikacje mają obsługiwać określone typy plików skryptowych (np. PHP) na poziomie konkretnego Virtual Host. Bez poprawnego handlera, PHP nie zadziała!
Kluczowe opcje:
- Suffixes
  Tu wpisujesz rozszerzenia plików, które mają być obsługiwane przez danego handlera.
  W typowej konfiguracji wpisujesz po prostu: nginxKopiujEdytujphp Dzięki temu wszystkie pliki z rozszerzeniem .php będą analizowane przez PHP.
Suffix – co to jest i jak go ustawić?
Suffix określa, jakie rozszerzenia plików skryptowych będą obsługiwane przez dany Script Handler. Każdy suffix musi być unikalny w konfiguracji.
Składnia:
- Lista rozszerzeń oddzielona przecinkami, bez kropki („.” jest niedozwolona).
- Przykład: KopiujEdytujphp,php83
Ważne uwagi (na podstawie dokumentacji OLS):
- Serwer automatycznie doda specjalny typ MIME (application/x-httpd-[suffix]) dla pierwszego sufiksu w tej liście.
  - Przykład: dla php83, zostanie dodany typ MIME application/x-httpd-php83.
- Jeśli chcesz używać dodatkowych sufiksów (np. php53,php74), po pierwszym musisz dodać odpowiadające typy MIME ręcznie w ustawieniach MIME.
- Choć pole „Suffix” wyświetla listę rozszerzeń, w praktyce handler korzysta z typów MIME, nie z samych sufiksów, aby zdecydować, które pliki obsłużyć.
- Podawaj tylko te rozszerzenia, których rzeczywiście używasz – nie wpisuj niepotrzebnych lub nieużywanych, by nie zwiększać ryzyka błędów lub ataków.
Przykład poprawnej konfiguracji:
Jeśli chcesz obsługiwać tylko pliki .php:
```
php
```
Jeśli chcesz obsługiwać również .php83:
```
php,php83
```
Pamiętaj, aby dla dodatkowych sufiksów dodać odpowiedni typ MIME w ustawieniach serwera!
- Handler Type
  Typ obsługiwacza skryptów.
  LiteSpeed SAPI to natywny, najwydajniejszy sposób obsługi PHP w OpenLiteSpeed – pozwala na bezpośrednią i szybką komunikację z interpreterem PHP, korzystając z ustawień z zakładki External App.
- Handler Name
  Wybierasz tu powiązaną aplikację zdefiniowaną w zakładce External App.
  Jeśli masz kilku Virtual Hostów, możesz mieć kilka różnych wersji PHP lub różnych konfiguracji.
  Uwaga:
  Warto, żeby tu było [VHost Level]: solutionsinc.co.uk – czyli handler, który został utworzony dla tej konkretnej strony.
Dlaczego to ważne?
- Bez poprawnego powiązania PHP z właściwym handlerem, serwer nie będzie wiedział, jak uruchamiać twoje pliki .php (może pobierać je jako pliki tekstowe zamiast wykonywać kod!).
- Wybór LiteSpeed SAPI gwarantuje najlepszą wydajność, bezpieczeństwo i obsługę nowoczesnych funkcji PHP.
- Jeśli masz kilka stron i każda ma inne wymagania (np. jedna działa na PHP 8.3, druga na PHP 8.1), możesz tu przypisać do każdej Virtual Host odpowiednią wersję interpreter PHP.
Zakładka Rewrite – do czego służy?
Zakładka Rewrite pozwala na zarządzanie regułami przepisywania URL-i (tzw. „mod_rewrite”), dzięki którym możesz:
- Tworzyć przyjazne adresy URL (np. w WordPress, Prestashop, Laravel).
- Wymuszać przekierowania (np. http→https, non-www→www).
- Realizować niestandardowe logiki przepisywania (np. maskowanie folderów, obsługa aliasów domen).
Opis pól
Rewrite Control
- Enable Rewrite
  Włącza obsługę mechanizmu przepisywania (mod_rewrite) dla tego Virtual Host.
  Ważne: Bez tego żadne reguły z .htaccess ani wpisy w „Rewrite Rules” nie będą działać!
- Auto Load from .htaccess
  Pozwala automatycznie ładować reguły rewrite z plików .htaccess znajdujących się w katalogach twojej strony.
  Ważne:
  - Dla WordPressa i większości popularnych CMS-ów koniecznie musi być „Yes”.
  - Jeśli chcesz mieć większą kontrolę nad wydajnością, możesz reguły rewrite wpisać bezpośrednio w „Rewrite Rules”, wtedy to pole można wyłączyć.
- Log Level
  - Określa poziom szczegółowości logów debugowania mechanizmu rewrite.
  - Zakres wartości: 0–9
    0 – wyłącza logowanie rewrite (brak logów).
    9 – najbardziej szczegółowe logi debugowania.
  - Im wyższa liczba, tym więcej szczegółowych informacji o działaniach reguł rewrite pojawi się w logach serwera.
  - Aby opcja działała, logi błędów serwera i/lub Virtual Host muszą mieć poziom co najmniej INFO.
  - Przydatne przy testowaniu i rozwiązywaniu problemów z regułami rewrite.
  - Syntax: Liczba całkowita z zakresu 0–9.
Rewrite Map
Możliwość zdefiniowania map przepisywania (zaawansowane – np. do dynamicznych przekierowań na podstawie wzorców lub plików).
- Dla większości użytkowników niewymagane.
Rewrite Rules
Miejsce na ręczne wpisanie reguł mod_rewrite (w stylu Apache).
Przykład:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Reguły tutaj mają wyższy priorytet niż te z .htaccess.
Dlaczego to ważne?
- Bez rewrite wiele aplikacji nie będzie działać poprawnie (brak przyjaznych linków, błędy 404).
- Automatyczne ładowanie z .htaccess pozwala korzystać z gotowych .htaccess od popularnych CMS-ów.
- Ręczne reguły przydają się, gdy potrzebujesz pełnej kontroli lub lepszej wydajności.
Zakładka Context – wszystkie pola
1. URI
- Opis: Ścieżka (URI) katalogu lub podkatalogu, dla którego tworzysz ten kontekst.
- Kluczowe! Musi dokładnie odpowiadać folderowi, gdzie znajduje się Twoja strona (np. /web/ dla katalogu /var/www/clients/client1/web1/web/).
- Uwaga: Jeśli URI kończy się na /, wszystkie podkatalogi są również objęte tym kontekstem. Jeśli twoja strona jest w katalogu głównym, wpisz po prostu /.
2. LSAPI App
- Opis: Wybierasz aplikację LiteSpeed SAPI (np. PHP) powiązaną z tym kontekstem. Lista rozwijana zawiera aplikacje zdefiniowane w External App.
- Dlaczego ważne? To łączy obsługę PHP (lub innego języka) z Twoją stroną. Bez tego, PHP nie będzie działać w tym katalogu!
3. Notes
- Opis: Pole informacyjne, możesz tu wpisać własne notatki.
- Wskazówka: Użyteczne przy większych instalacjach lub testach, ale pole nie jest obowiązkowe.
4. Header Operations
- Opis: Dodatkowe operacje na nagłówkach odpowiedzi HTTP (np. ustawianie, dodawanie, kasowanie nagłówków).
- Składnia: Zbliżona do Apache mod_headers.
- Przykład: pgsqlKopiujEdytujset Cache-control no-cache append Cache-control no-store
- Wskazówka: Przydatne, gdy chcesz sterować cache’owaniem lub bezpieczeństwem na poziomie katalogu.
5. Realm / Authentication Name / Require (Authorized Users/Groups) / Access Allowed / Access Denied / Authorizer
- Opis: Opcje autoryzacji dostępu do danego katalogu (możesz tu ustawić prostą ochronę hasłem, dostęp tylko dla wybranych grup/użytkowników).
- Wskazówka: Domyślnie zostawiasz puste. Stosujesz, jeśli chcesz ograniczyć dostęp do panelu admina, katalogu testowego itp.
6. Add Default Charset
- Opis: Określa, czy domyślny zestaw znaków ma być dodany do odpowiedzi HTTP.
- Domyślnie: Off
- Ustaw, jeśli: Masz stronę o nietypowym kodowaniu lub chcesz wymusić np. UTF-8.
7. Customized Default Charset
- Opis: Pozwala wskazać własny domyślny zestaw znaków (np. UTF-8, ISO-8859-2).
- Ustaw, jeśli: Potrzebujesz specyficznego kodowania znaków.
8. Enable GeoLocation Lookup
- Opis: Pozwala włączyć sprawdzanie lokalizacji geograficznej użytkowników na podstawie IP.
- Wskazówka: Zostaw domyślnie wyłączone, chyba że tworzysz stronę z personalizacją wg kraju.
Dlaczego ta zakładka jest ważna?
- Dzięki Context możesz precyzyjnie ustawić, jak serwer ma obsługiwać wybrane katalogi/podkatalogi, np. wybrać inną wersję PHP dla /admin/, zabezpieczyć panel logowania, zmienić nagłówki bezpieczeństwa tylko w jednym folderze.
- URI to absolutna podstawa – błędne ustawienie tej ścieżki sprawi, że ustawienia nie zadziałają!
- Dzięki temu masz elastyczność niedostępną w prostych hostingach.
Podsumowanie
Po wykonaniu wszystkich powyższych kroków – od konfiguracji ISPConfig, przez ustawienie Nginx jako reverse proxy, po precyzyjne dobranie opcji w OpenLiteSpeed – Twoja strona WordPress lub dowolna inna aplikacja powinna działać jak złoto. Oczywiście pod warunkiem, że nie zapomniałeś o poprawnych rekordach DNS (np. w CloudFlare) – bez nich nawet najpiękniej skonfigurowany serwer będzie świecił pustkami jak lodówka po sesji!
Jeśli wszystko śmiga, gratulacje – możesz teraz spokojnie napić się herbaty, bo Twój serwer właśnie wszedł na wyższy poziom! Jeśli coś nie działa… cóż, sprawdź jeszcze raz DNS, logi oraz to, czy przypadkiem nie wpadłeś na pomysł zrobienia wszystkiego o 3 w nocy. Powodzenia!
28 czerwca, 2025

Kategoria: ISPConfig

WordPress i błąd „A scheduled event has failed”?

Czym jest WP-Cron?

Scenariusz 1: Pojedyncza strona WordPress

Scenariusz 2: Wiele stron na standardowym serwerze

Scenariusz 3: Wiele stron z panelem ISPConfig

Podsumowanie

OpenLiteSpeed (OLS) z Redis. Szybka pamięć Cache dla stron WordPress.

Sekcja 1: OpenLiteSpeed (OLS) – Rdzeń Systemu

Czym jest OpenLiteSpeed?

Kluczowe Funkcje OpenLiteSpeed

Sekcja 2: Redis – Akcelerator Danych w Pamięci Operacyjnej

Czym jest Redis?

Jak Działa Współpraca OpenLiteSpeed i Redis?

Sekcja 3: Delegowanie Zadań – Aplikacje Zewnętrzne w OLS

Sekcja 4: Język Komunikacji – Porównanie Architektur SAPI

Ewolucja SAPI

Tabela Porównawcza Architektur SAPI

Porównanie Gniazd Komunikacyjnych

Sekcja 5: Praktyczna Implementacja i Zarządzanie

5.1 Analiza Konfiguracji na Przykładzie solutionsinc.co.uk

5.2 Zarządzanie Gniazdami Domeny Uniksowej (.sock) i Rozwiązywanie Problemów

Sekcja 6: Podsumowanie

Ubuntu Server 24.04 + ISPConfig (Nginx) + OpenLiteSpeed: Nowoczesny i Wydajny Serwer WWW i Email bez CyberPanel

Wstęp

Dlaczego warto tworzyć osobnych klientów dla każdej strony w ISPConfig?

Limity i bezpieczeństwo w ISPConfig – dlaczego to takie ważne?

Przykładowe limity, które możesz ustawić:

Bezpieczne hasło – Twój pierwszy mur obronny

Opis opcji sekcji „Web Limits” w ISPConfig

Opis opcji sekcji „Email Limits” w ISPConfig

Tworzenie użytkownika bazy danych dla strony – ISPConfig

Opis opcji zakładki „Domain” przy tworzeniu strony WWW w ISPConfig

Opis opcji zakładki „Redirect” w ISPConfig (Reverse Proxy)

Zakładka SSL w ISPConfig – co tutaj ustawić?

Zakładka Statistics w ISPConfig – własne statystyki dla Twojej strony

Zakładka Backup – Twoja sieć bezpieczeństwa (i spokój ducha)

Zakładka Options – kluczowa dla Reverse Proxy (Nginx → OLS)

Ostatni krok: konfiguracja OpenLiteSpeed pod Reverse Proxy

Virtual Hosts > Basic w OpenLiteSpeed – jak poprawnie uzupełnić?

Zakładka General – OpenLiteSpeed Virtual Host

Najważniejsze opcje:

Pozostałe opcje:

Sekcja Index Files:

Customized Error Pages:

Expires Settings:

File Upload:

php.ini Override:

Zakładka Log – niezależne logi dla każdej witryny

Dlaczego warto ustawić osobne logi?

Virtual Host Log (log błędów)

Access Log (log dostępu)

Zalecane ustawienia:

Zakładka Security – opis wszystkich opcji

Sekcja: LS reCAPTCHA

Sekcja: Containers

Sekcja: Access Control

Sekcja: Realm List

Podsumowanie praktyczne

Zakładka External App – opis i zalecenia

Najważniejsze pola:

Zakładka Script Handler – do czego służy?

Kluczowe opcje:

Suffix – co to jest i jak go ustawić?

Składnia:

Ważne uwagi (na podstawie dokumentacji OLS):

Przykład poprawnej konfiguracji:

Dlaczego to ważne?

Zakładka Rewrite – do czego służy?

Opis pól

Dlaczego to ważne?

Zakładka Context – wszystkie pola

1. URI

2. LSAPI App

3. Notes

4. Header Operations

5. Realm / Authentication Name / Require (Authorized Users/Groups) / Access Allowed / Access Denied / Authorizer

6. Add Default Charset

7. Customized Default Charset

8. Enable GeoLocation Lookup

5.1 Analiza Konfiguracji na Przykładzie `solutionsinc.co.uk`

5.2 Zarządzanie Gniazdami Domeny Uniksowej (`.sock`) i Rozwiązywanie Problemów