WordPress za reverse proxy: jak naprawić przekierowania i HTTPS

WordPress za reverse proxy psuje się z jednego prostego powodu: WordPress nie widzi protokołu ani hosta, z których naprawdę skorzystał odwiedzający. Trzeba więc przekazać te informacje z warstwy proxy i pozwolić, żeby wp-config.php je odczytał. Tak naprawdę to cała poprawka. Utknąłeś w niekończących się przekierowaniach w wp-admin? Przeglądarka ostrzega przed mixed content? Mapa strony jest pełna linków http:// i adresu IP serwera origin? Poniżej przechodzę po kolei przez konfigurację NGINX na serwerze origin, wp-config.php, ustawienia adresu strony, czyszczenie bazy danych i końcowe sprawdzenie.

Dlaczego WordPress za reverse proxy źle obsługuje przekierowania i HTTPS?

WordPress ocenia, czy żądanie jest bezpieczne, na podstawie własnych zmiennych serwera. Odwiedzający łączy się przez HTTPS, proxy rozmawia z serwerem origin zwykłym HTTP, a WordPress widzi wyłącznie ten drugi, nieszyfrowany odcinek. Dlatego w kółko odsyła przeglądarkę do wersji HTTPS strony, którą uważa za niezabezpieczoną. I tak bez końca. Poradnik WordPressa o HTTPS mówi to wprost: proxy, które zapewnia SSL przed serwerem origin bez SSL, wpycha żądania w nieskończoną pętlę przekierowań, gdy tylko włączysz FORCE_SSL_ADMIN. Ta sama strona zwraca też uwagę, że proxy pass przekazuje żądanie, ale nie nagłówki, których WordPress potrzebuje do przekierowań. Musisz dodać je sam. (Nie masz pewności, czy taka architektura pasuje do Twojej strony? Najpierw przeczytaj, kiedy reverse proxy ma sens.)

Krok 1: przekaż właściwe nagłówki z NGINX do serwera origin

Zacznij od serwera NGINX, który kontrolujesz i który stoi przed WordPressem. Każda lokalizacja obsługiwana przez proxy musi przekazywać oryginalny host i schemat, bez wyjątków. Dodaj te dyrektywy do bloku location, który przekazuje ruch:

1. proxy_set_header Host $host; zachowuje publiczną domenę zamiast nazwy upstreamu.
2. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; przekazuje adres odwiedzającego dalej w łańcuchu.
3. proxy_set_header X-Forwarded-Proto $scheme; informuje serwer origin, czy odwiedzający przyszedł przez HTTP, czy przez HTTPS.
4. proxy_set_header X-Forwarded-Host $host; przydaje się, gdy serwer origin obsługuje kilka nazw albo stoi za jeszcze jedną warstwą.

A co z przekierowaniami, które zdradzają adres upstreamu? To też da się załatwić. W dokumentacji modułu proxy NGINX jest wyjaśnione, że proxy_redirect przepisuje nagłówki Location i potrafi dodać nazwę hosta do względnych przekierowań z serwera za proxy. Jednego bym się trzymał bezwzględnie: ufaj przekazanym nagłówkom tylko wtedy, gdy przychodzą ze znanych adresów proxy. Niezależnie od tego, z jakiej usługi korzystasz do kierowania WordPressa na IP proxy, weź listę tych adresów i nie pozwól, żeby ktokolwiek inny ustawiał wartości X-Forwarded-*. Nagłówek może wysłać każdy.

Krok 2: naucz wp-config.php czytać HTTP_X_FORWARDED_PROTO

Pętla przekierowań znika, gdy wp-config.php oznacza żądanie jako bezpieczne za każdym razem, kiedy proxy zgłasza HTTPS. Wklej ten fragment nad linią „That’s all, stop editing”:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}
define( 'FORCE_SSL_ADMIN', true );

Stałe takie jak FORCE_SSL_ADMIN umieszcza się w wp-config.php. Nie we wtyczce. Dokumentacja WordPressa mówi, że zdefiniowanie ich we wtyczce nie wystarczy, a ludzie i tak próbują. Żeby zablokować podszywanie się, otocz ten test warunkiem, który porównuje $_SERVER[’REMOTE_ADDR’] z adresami Twojego proxy. Skąd wiadomo, że zadziałało? wp-admin ładuje się raz, bez skakania między adresami URL.

Krok 3: ustaw adres strony WordPressa za proxy

Zdefiniuj WP_HOME i WP_SITEURL w wp-config.php z publiczną domeną HTTPS. Nigdy z IP serwera origin, nigdy z wewnętrzną nazwą hosta. WordPress buduje z tych dwóch wartości każdy link bezwzględny, więc jeden błędny wpis rozlewa się jednocześnie na mapę strony, tagi canonical i kanał RSS:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Potem wyłap wszystko, co zapamiętało stary adres. Wtyczki SEO często trzymają wygenerowaną mapę strony, którą trzeba wygenerować od nowa. Zapisanie ustawień bezpośrednich odnośników odświeża reguły przepisywania. A motywy? Niektóre trzymają w opcjach własną kopię adresu strony, co jest irytujące, ale częste. Ta sama dyscyplina obowiązuje przy przenoszeniu stron między pulami IP, bo wyszukiwarki podchwytują każdy URL, który pokazują Twoje strony.

Jak naprawić mixed content po przejściu na proxy?

Mixed content po przełączeniu na proxy bierze się z adresów http:// zapisanych w bazie danych. To nie proxy jest tu winne. Wpisy, opcje i widżety przechowują adres, który obowiązywał w chwili ich zapisania. Przejdź przez te punkty:

• Najpierw zrób kopię zapasową bazy. Potem uruchom wp search-replace 'http://example.com’ 'https://example.com’ -dry-run, żeby podejrzeć zmiany, zanim wprowadzisz je naprawdę.
• Sprawdź opcje motywu i dane page buildera, które uwielbiają trzymać własne kopie adresów obrazków i linków.
• Zaktualizuj zaszyte na sztywno adresy zasobów w motywach potomnych, własnym CSS i skryptach w nagłówku.

Używaj wp-cli, a nie surowego SQL. WordPress przechowuje dane serializowane ze znacznikami długości, a zwykła podmiana tekstu je uszkodzi (zapytaj kogokolwiek, kto musiał ręcznie odbudowywać obszar widżetów). Jeśli w grę wchodzą certyfikaty albo zewnętrzne hosty zasobów, przejrzyj też swoje ślady TLS i CDN.

Weryfikacja konfiguracji i najczęstsze błędy

Sprawdź poprawkę z zewnątrz, tak jak widzą stronę odwiedzający i crawler. Uruchom curl -IL na publicznym adresie URL i prześledź łańcuch przekierowań. Powinien kończyć się na jednej stronie HTTPS. Otwórz konsolę przeglądarki i poszukaj ostrzeżeń o mixed content. Potem wczytaj mapę strony i upewnij się, że każdy wpis używa HTTPS i publicznego hosta.

Jeśli nadal nie działa, zwykle winny jest jeden z kilku błędów:

• Wymuszanie HTTPS jednocześnie w NGINX i we wtyczce WordPressa. Dwa zestawy przekierowań, które walczą ze sobą.
• Edycja konfiguracji bez przeładowania NGINX. Zdarza się częściej, niż ktokolwiek przyznaje.
• Ustawienie nagłówków tylko w jednym bloku location, przez co żądania PHP albo panelu admina nigdy ich nie dostają.
• Nieaktualny cache stron na serwerze origin, który dalej serwuje stary kod z http://.

WordPress za reverse proxy działa stabilnie, gdy serwer origin zna prawdziwy schemat i host. Przekaż nagłówki, odczytaj je w wp-config.php, ustaw na sztywno publiczny adres, wyczyść bazę. To wszystko. Jeśli interesują Cię pokrewne tematy konfiguracji, zajrzyj do poradników o proxy i hostingu.

FAQ