Jak używać proxy z WordPressem

WordPress nie potrzebuje proxy do każdego żądania. Jest ono potrzebne przy konkretnych zadaniach: sprawdzaniu aktualizacji po stronie panelu administracyjnego, zdalnych wywołaniach API, weryfikacji licencji oraz zadaniach indeksowania uruchamianych z serwera, a nie z przeglądarki odwiedzającego. To rozróżnienie ma ogromne znaczenie.

Jeśli chcesz zrozumieć, jak używać proxy z WordPressem, zacznij od nazwania ruchu, który naprawdę chcesz przekierować. Proxy nie jest magicznym przełącznikiem dla całej witryny, a przepychanie przez nie każdego żądania może narobić więcej problemów, niż rozwiąże. Jeśli zastanawiasz się, jak ustawić proxy w WordPressie, pamiętaj, że jeden przykład to wtyczka, która łączy się z serwerem w celu sprawdzenia aktualizacji — może nie działać z sieci hostingu, podczas gdy publiczne strony nadal będą ładować się bez problemu dla odwiedzających.

1. Określ ruch WordPressa, który powinien przechodzić przez proxy

WordPress wysyła kilka rodzajów żądań wychodzących, a tylko część z nich powinna działać przez proxy. Najczęściej są to sprawdzenia aktualizacji rdzenia, aktualizacji wtyczek i motywów, zdalne żądania API z wtyczek oraz automatyczne zadania indeksowania lub importu uruchamiane z wp-admin albo WP-CLI. To są żądania po stronie serwera. Wychodzą z hosta, a nie z laptopa odwiedzającego.

Trzymaj tę listę wąsko. Jeśli przez pomyłkę skierujesz przez proxy zwykłe przeglądanie front-endu, możesz spowolnić całą stronę albo zepsuć skrypty zewnętrzne, które oczekują zwykłego adresu IP serwera. W przypadku małego sklepu lepszym wyborem często jest proxy tylko dla ruchu aktualizacji i API. W środowisku stagingowym proxy może być potrzebne wyłącznie na czas testów.

Pomaga jeden krótki test. Wyłącz proxy, uruchom zadanie, a potem włącz je ponownie i wykonaj to samo zadanie jeszcze raz. Jeśli zachowanie zmienia się tylko dla żądania administracyjnego, wybrałeś właściwy ruch.

2. Sprawdź, co w WordPressie można faktycznie objąć proxy

Są tu trzy poziomy: sam serwer WordPressa, wychodzące żądania HTTP WordPressa oraz logika żądań pojedynczej wtyczki. To nie jest to samo. Proxy na poziomie serwera oznacza zmianę ścieżki sieciowej dla wszystkiego, co opuszcza host. Proxy dla żądań HTTP WordPressa wpływa na żądania wykonywane przez WordPress HTTP API. Proxy na poziomie wtyczki jest jeszcze bardziej zawężone i często bezpieczniejsze.

Odwiedzający front-end to zupełnie inna historia. Ich ruch w przeglądarce nie staje się proxy tylko dlatego, że serwer WordPress ma ustawienie proxy. Odwiedzający ładujący stronę z Europy nadal pobiera ją z normalnej publicznej witryny, chyba że zmieniasz też DNS, zachowanie CDN albo konfigurację przeglądarki użytkownika. Inna warstwa, inny efekt.

To rozdzielenie ma znaczenie, gdy wtyczka pobiera zdalny kanał danych. Wywołanie kanału może przechodzić przez proxy, a strona wyświetlana użytkownikowi już nie. I dobrze. Zwykle właśnie tego chcesz.

3. Zbierz dane proxy, których WordPress może użyć

WordPress potrzebuje czterech podstawowych danych do konfiguracji proxy: hosta, portu, protokołu oraz danych uwierzytelniających, jeśli proxy jest chronione. Nie zgaduj ich. Literówka w porcie albo brak hasła mogą sprawić, że każde żądanie wychodzące zakończy się niepowodzeniem, a komunikat o błędzie bywa na tyle nieprecyzyjny, że zmarnujesz godzinę.

Jeśli dostawca proxy podaje endpoint z uwierzytelnianiem, zapisz dokładny format logowania. Niektóre proxy używają nazwy użytkownika i hasła w adresie URL, inne oczekują osobnego kroku autoryzacji. Więcej informacji o formatach i ograniczeniach znajdziesz w przewodniku po najlepszych praktykach uwierzytelniania proxy. Jedna uwaga: nie wszystkie wtyczki WordPressa obsługują uwierzytelnianie tak samo.

Sprawdź też, czy proxy jest HTTP czy SOCKS5. Ten wybór wpływa na zgodność. Jeśli chcesz szybkiego porównania, artykuł o proxy SOCKS5 a proxy HTTP wyjaśnia, dlaczego niektóre zadania WordPressa działają lepiej z jednym lub z drugim. Przy zdalnym wywołaniu API HTTP często wystarcza. Do szerszego routingu sieciowego lepszy może być SOCKS5.

4. Dodaj ustawienia proxy przez konfigurację WordPressa

Rdzeń WordPressa może odczytywać ustawienia związane z proxy z konfiguracji, zwykle z pliku wp-config.php albo ze środowiska hostingu. Praktyczny cel to wpływ na wychodzące żądania HTTP rdzenia bez ruszania motywu. Oznacza to ustawienia blisko początku pliku konfiguracyjnego, przed załadowaniem WordPressa, albo zmienne środowiskowe wstrzykiwane w czasie działania przez hosting.

Dokładne stałe zależą od hosta i zestawu wtyczek. W wielu konfiguracjach definiuje się host proxy, port i ewentualne reguły obejścia w pliku konfiguracyjnym, aby WordPress wiedział, dokąd wysyłać wychodzące wywołania HTTP API. Jeśli host obsługuje wartości środowiskowe, może to być lepsze niż wpisywanie danych uwierzytelniających na sztywno do pliku. Lepsze, ale nie idealne. W praktyce wiele osób szuka właśnie frazy proxy WordPress wp-config.php, ponieważ to najprostszy punkt startowy do konfiguracji.

Trzymaj zakres wąsko. Proxy na poziomie konfiguracji powinno dotyczyć wychodzących żądań samego WordPressa, a nie całej ścieżki odwiedzającego. Jeśli nie masz pewności, którą ścieżkę zmieniasz, zatrzymaj się i przetestuj wszystko najpierw na stagingu. Jedna błędna linia w wp-config.php może wpłynąć na sprawdzanie aktualizacji w całej witrynie.

Przy planowaniu proxy i pytaniach o skalę pomaga też wiedza o tym, ile kosztuje proxy. Cena ma znaczenie, gdy wtyczka wykonuje dziesiątki zdalnych wywołań dziennie, zwłaszcza w instalacji multisite z powtarzającymi się kontrolami.

5. Zastosuj proxy tylko do tych żądań, które go potrzebują

Nie każde żądanie powinno przechodzić przez to samo proxy. Haki WordPressa i ustawienia wtyczek pozwalają kierować przez proxy tylko wybrane wywołania wychodzące. To bezpieczniejsza opcja dla sklepów, serwisów członkowskich i każdej instalacji, która komunikuje się z więcej niż jedną usługą zewnętrzną. Wymuszenie zbyt dużego ruchu przez jedno proxy tworzy pojedynczy punkt awarii.

Typowy wzorzec to przekierowanie sprawdzania licencji jednej wtyczki przez proxy, przy jednoczesnym pozostawieniu innych żądań bezpośrednio. Inny przykład to kierowanie tylko wywołań do konkretnego endpointu API, na przykład kanału cenowego albo katalogu produktów. Właśnie tutaj liczy się hook lub filtr wtyczki. Kod może sprawdzić adres docelowy i zdecydować, czy dołączyć ustawienia proxy, czy zostawić żądanie w spokoju.

To rozwiązanie jest czyściejsze niż globalne proxy. W witrynie, która wysyła dane do CRM, synchronizuje się z API wysyłki i sprawdza aktualizacje na WordPress.org, wywołanie do CRM może wymagać proxy, a dwa pozostałe nie. Trzy wywołania. Trzy decyzje.

Jeśli Twoja konfiguracja obejmuje endpointy z uwierzytelnianiem, przed podłączeniem warstwy żądań sprawdź uwagi dotyczące uwierzytelnianego proxy SOCKS5. Mała niezgodność, duży problem.

6. Po konfiguracji przetestuj aktualizacje wtyczek, wywołania API i zdalny dostęp

Testy powinny być konkretne. Nie ograniczaj się do otwarcia strony głównej i uznania sprawy za zakończoną. Sprawdź aktualizacje wtyczek, aktualizacje motywów, integracje REST lub API, weryfikację licencji oraz wszystkie zdalne pobrania mediów wykonywane przez wtyczki. Każde z tych działań wykorzystuje WordPress inaczej i jedno może przejść, podczas gdy inne zawiedzie.

Spróbuj ręcznie sprawdzić aktualizacje z poziomu kokpitu. Potem uruchom własną zdalną akcję wtyczki, jeśli taką ma. Jeśli wtyczka pobiera JSON z serwera dostawcy, upewnij się, że dane docierają. Jeśli witryna importuje media z innej domeny, sprawdź, czy obrazy nadal się pobierają. Jeden brakujący certyfikat SSL może przerwać cały łańcuch.

Znaczenie ma też czas. Zdalne żądanie, które działa raz, może przekroczyć limit czasu przy drugiej próbie, jeśli proxy jest wolne albo host blokuje powtarzające się wywołania. Jeśli brzmi to znajomo, porównaj to z poradami z artykułu jak wybrać VPN, ponieważ ta sama logika decyzyjna dotycząca niezawodności i routingu często ma zastosowanie.

W przypadku crawlerów, kanałów danych i powtarzalnych pobrań przyda się artykuł o rotacji proxy w web scrapingu, który pomoże przeanalizować wielokrotne żądania wychodzące. WordPress domyślnie nie służy do scrapingu, ale niektóre wtyczki pod obciążeniem zachowują się dokładnie tak.

7. Rozwiązywanie problemów z WordPressem i proxy

Nieudane sprawdzanie aktualizacji zwykle jest pierwszym sygnałem. Kolejnym częstym problemem są kłopoty z autoryzacją. Jeśli proxy wymaga danych logowania, a WordPress nie może ich poprawnie wysłać, żądania mogą zwracać kod 407 albo po prostu kończyć się przekroczeniem czasu oczekiwania. Najpierw sprawdź host, port, nazwę użytkownika i hasło. Potem sprawdź protokół.

Potem pojawiają się błędy weryfikacji SSL. WordPress może ufać zdalnej witrynie, ale nie ścieżce przez proxy, albo proxy może zakłócać obsługę certyfikatów. Jeśli usługa zdalna używa rygorystycznego TLS, proxy musi przekazywać ten ruch bez zakłóceń. Nie wyłączaj sprawdzania certyfikatów na skróty, chyba że dokładnie rozumiesz ryzyko. Taki skrót może ukryć prawdziwy problem.

Przekroczenia czasu oczekiwania często oznaczają, że proxy jest wolne, zablokowane albo przeciążone. Spróbuj najpierw pojedynczego żądania z krótką ścieżką, a potem drugiego żądania do tego samego endpointu. Jeśli jedno przechodzi, a drugie nie, możliwe, że proxy ogranicza częstotliwość. Inną możliwością jest blokada po stronie hosta. Niektóre usługi zdalne odrzucają ruch z rozpoznawalnych zakresów proxy.

Jeśli problem wygląda na zamieszanie z portem, sprawdź numer portu jeszcze raz. Niezgodność między portem proxy a portem usługi wystarczy, by WordPress nie mógł dotrzeć do zdalnego hosta. Głębsze omówienie znajdziesz w artykule o numerach portów proxy w web scrapingu. Temat jest szerszy niż WordPress, ale logika portów jest taka sama.

I jeszcze jedno: jeśli Twoje proxy oczekuje określonej listy dozwolonych adresów IP, host może wymagać dodania do niej, zanim WordPress będzie mógł się połączyć. Bez tego żądanie kończy się niepowodzeniem, zanim dotrze do celu. Twarda blokada. Bez częściowego sukcesu.

8. Bezpiecznie wycofaj lub wyłącz proxy

Wycofanie powinno być nudne. Usuń stałe proxy lub wartości środowiskowe, wyczyść wszystkie pola proxy specyficzne dla wtyczek i przeładuj WordPress. Zrób to w trybie konserwacji, jeśli witryna jest pod ruchem. Potem potwierdź, że serwis może łączyć się z tymi samymi usługami zdalnymi bezpośrednio.

Po usunięciu ustawień przetestuj te same czynności, które sprawdzałeś wcześniej: kontrolę aktualizacji, wywołania API, weryfikację licencji i pobieranie zdalnych mediów. Jeśli wszystkie działają bez proxy, potwierdziłeś, że WordPress wrócił do bezpośrednich połączeń. Jeśli któraś usługa nadal zawodzi, proxy mogło być tylko częścią rozwiązania, co oznacza, że za nim kryje się jeszcze inne ograniczenie sieciowe.

Na koniec przejrzyj wszelkie tymczasowe dane uwierzytelniające zapisane w konfiguracji lub zmiennych środowiskowych i usuń je z hosta, jeśli nie są już potrzebne. To utrzymuje porządek w konfiguracji. Chroni też przed przypadkowym użyciem starego proxy pół roku później, a zdarza się to częściej, niż zespoły chcą przyznać.