Як використовувати проксі з WordPress

WordPress не потребує проксі для кожного запиту. Він потрібен для конкретних завдань: перевірок оновлень з адмінки, віддалених API-запитів, перевірки ліцензій і задач сканування сайту, які запускаються із сервера, а не з браузера відвідувача. Ця різниця має велике значення.

Якщо ви намагаєтеся зрозуміти як використовувати проксі з WordPress або шукаєте, як налаштувати проксі в WordPress, спершу визначте, який саме трафік ви хочете перенаправити. Проксі — це не чарівний перемикач для всього сайту, і якщо пропускати через нього кожен запит, проблем може стати більше, ніж користі. Наприклад, плагін, який звертається до сервера за оновленням, може не спрацювати з хостингової мережі, тоді як публічні сторінки для відвідувачів і далі завантажуватимуться нормально.

1. Визначте трафік WordPress, який має проходити через проксі

WordPress виконує кілька типів вихідних запитів, і лише частина з них має йти через проксі. Найпоширеніші — перевірка оновлень ядра, перевірка оновлень плагінів і тем, запити до віддалених API з боку плагінів, а також автоматичне сканування чи імпорт, запущені з wp-admin або WP-CLI. Це серверні запити. Вони виходять із хоста, а не з ноутбука відвідувача.

Тримайте список коротким. Якщо помилково пропустити через проксі звичайний фронтенд-трафік, можна загальмувати весь сайт або зламати сторонні скрипти, які очікують звичайну IP-адресу вашого сервера. Для невеликого інтернет-магазину кращим вибором часто є проксування лише трафіку оновлень та API. Для staging-середовища проксі може знадобитися тільки під час тестів.

Допомагає коротка перевірка. Вимкніть проксі, запустіть задачу, потім увімкніть його знову і виконайте ту саму задачу ще раз. Якщо поведінка змінюється лише для запиту з адмінки, ви вибрали правильний трафік.

2. Переконайтеся, де саме у WordPress можна застосувати проксі

Тут є три рівні: сам сервер WordPress, вихідні HTTP-запити WordPress і логіка запиту окремого плагіна. Це не одне й те саме. Проксування самого сервера означає зміну мережевого шляху для всього, що виходить із хоста. Проксування HTTP-запитів WordPress означає вплив на запити, які йдуть через WordPress HTTP API, тобто на проксі для WordPress HTTP API. Проксування на рівні плагіна ще вужче і часто безпечніше.

Поведінка фронтенд-відвідувачів — це інша історія. Їхній браузерний трафік не стане проксованим лише тому, що на сервері WordPress увімкнено налаштування проксі. Відвідувач, який відкриває сторінку з Європи, і далі завантажує її з вашого звичайного публічного сайту — якщо тільки ви також не змінюєте DNS, поведінку CDN або налаштування браузера самого відвідувача. Інший рівень — інший результат.

Таке розділення важливе, коли плагін отримує віддалений фід. Виклик фіда може йти через проксі, а сторінка, яку бачить користувач, — ні. І це добре. Саме так зазвичай і має бути.

3. Зберіть дані проксі, які може використати WordPress

WordPress потребує чотири базові параметри для налаштування проксі: хост, порт, протокол і, якщо проксі захищений, облікові дані. Не вгадуйте їх. Помилка в порті або відсутній пароль можуть зламати всі вихідні запити, а повідомлення про помилку часто настільки нечітке, що ви втратите годину часу.

Якщо ваш провайдер проксі дає вам автентифіковану кінцеву точку, збережіть точний формат входу. Деякі проксі використовують ім’я користувача та пароль в URL, інші очікують окремий крок автентифікації. Для загального розуміння форматів і обмежень дивіться гайд із найкращих практик автентифікації проксі. Одне зауваження: не всі плагіни WordPress однаково працюють з автентифікацією.

Також перевірте, чи є проксі HTTP або SOCKS5. Від цього залежить сумісність. Якщо вам потрібне коротке порівняння, стаття SOCKS5 чи HTTP проксі для вебскрапінгу пояснює, чому деякі задачі WordPress працюють краще з одним типом, ніж з іншим. Для віддаленого API-запиту HTTP часто достатньо. Для ширшого мережевого маршрутизації SOCKS5 може підійти краще.

4. Додайте налаштування проксі через конфігурацію WordPress

Ядро WordPress може зчитувати параметри проксі з конфігурації, зазвичай із wp-config.php або з оточення хостингу. Практична мета — вплинути на вихідні HTTP-запити ядра, не чіпаючи тему. Це означає параметри ближче до початку конфігураційного файлу, до завантаження WordPress, або змінні середовища, які хост підставляє під час виконання.

Точні константи залежать від хосту та набору плагінів. У багатьох конфігураціях ви задаєте хост проксі, порт і будь-які правила обходу в конфігурації, щоб WordPress знав, куди надсилати свої вихідні HTTP API-запити. Якщо ваш хост підтримує змінні середовища, це може бути чистіше, ніж жорстко прописувати облікові дані у файлі. Чистіше, але не ідеально.

Тримайте область дії вузькою. Проксі на рівні конфігурації має стосуватися лише вихідних запитів WordPress, а не всього шляху відвідувача. Якщо ви не впевнені, який саме шлях змінюєте, зупиніться і спершу протестуйте на staging. Один неправильний рядок у wp-config.php може вплинути на перевірку оновлень по всьому сайту.

Для планування проксі та питань масштабу також корисно знати скільки коштує проксі. Ціна має значення, коли плагін робить десятки віддалених викликів на день, особливо на мультисайті з повторними перевірками.

5. Застосовуйте проксі лише до тих запитів, яким він потрібен

Не кожен запит має проходити через один і той самий проксі. Хуки WordPress і налаштування плагінів дозволяють спрямовувати через проксі лише вибрані вихідні виклики. Це безпечніший підхід для магазинів, сайтів із підпискою та будь-яких інсталяцій, які взаємодіють із кількома зовнішніми сервісами. Якщо примусово пропускати занадто багато трафіку через один проксі, ви створюєте єдину точку відмови.

Поширений сценарій — проксувати перевірку ліцензії одного плагіна, залишаючи інші запити прямими. Інший варіант — маршрутизувати лише виклики до певного API-ендпойнта, наприклад до фіду цін або каталогу товарів. Саме тут важливі хук або фільтр плагіна. Код може перевірити адресу призначення, а потім вирішити, чи додавати налаштування проксі, чи залишити запит без змін.

Такий підхід чистіший за глобальне проксування. Для сайту, який надсилає дані в CRM, синхронізується з API доставки та перевіряє оновлення на WordPress.org, виклик до CRM може потребувати проксі, тоді як інші два — ні. Три виклики. Три рішення.

Якщо у вашій схемі є автентифіковані кінцеві точки, перед налаштуванням рівня запитів перегляньте нотатки про автентифікований SOCKS5 проксі. Маленька невідповідність — велика морока.

6. Перевірте оновлення плагінів, API-запити та віддалений доступ після налаштування

Тестування має бути точним. Не просто відкрийте головну сторінку й вважайте, що все готово. Перевірте оновлення плагінів, оновлення тем, REST- або API-інтеграції, перевірку ліцензії та будь-які запити до віддалених медіа, які виконують ваші плагіни. Усі вони використовують WordPress по-різному, і один може спрацювати, тоді як інший — ні.

Спробуйте вручну запустити перевірку оновлень із панелі керування. Потім, якщо плагін має власну віддалену дію, запустіть її. Якщо плагін отримує JSON із сервера постачальника, переконайтеся, що дані приходять. Якщо ваш сайт імпортує медіа з іншого домену, переконайтеся, що зображення все ще завантажуються. Один відсутній SSL-сертифікат може зламати весь ланцюжок.

Важливий і час відповіді. Віддалений запит, який працює один раз, може завершитися тайм-аутом під час другої спроби, якщо проксі повільний або хост блокує повторні запити. Якщо це знайомо, порівняйте з порадами з статті про те, як вибрати VPN, бо той самий логічний підхід до надійності та маршрутизації часто застосовується й тут.

Для краулерів, фідів і повторних звернень стаття про ротацію проксі для вебскрейпінгу допоможе продумати повторні вихідні запити. WordPress за замовчуванням не займається скрейпінгом, але деякі плагіни під навантаженням поводяться саме так.

7. Усуньте збої WordPress, пов’язані з проксі

Невдалі перевірки оновлень зазвичай є першою ознакою. Наступна поширена проблема — автентифікація. Якщо проксі вимагає облікові дані, а WordPress не може передати їх правильно, запити можуть повертати 407 або просто завершуватися тайм-аутом. Спершу перевірте хост, порт, ім’я користувача і пароль. Потім перевірте протокол.

Далі йдуть помилки перевірки SSL. WordPress може довіряти віддаленому сайту, але не довіряти шляху через проксі, або проксі може заважати обробці сертифікатів. Якщо віддалений сервіс використовує жорсткий TLS, проксі має передавати цей трафік без спотворень. Не вимикайте перевірку сертифікатів як швидке рішення, якщо не розумієте всіх ризиків. Такий обхід може приховати реальну проблему.

Тайм-аути часто означають, що проксі повільний, заблокований або перевантажений. Спробуйте один запит з коротким маршрутом, а потім другий запит до того самого ендпойнта. Якщо один проходить, а інший ні, можливо, проксі обмежує частоту запитів. Також можлива блокировка з боку хоста. Деякі віддалені сервіси взагалі відхиляють трафік із відомих діапазонів проксі.

Якщо проблема схожа на плутанину з портом, перевірте номер порту ще раз. Невідповідність між портом проксі та портом сервісу може бути достатньою, щоб WordPress не зміг дістатися до віддаленого хоста. Для глибшої перевірки дивіться номери портів проксі для вебскрейпінгу. Тема ширша за WordPress, але логіка портів така сама.

І ще одне: якщо ваш проксі очікує певний allowlist IP-адрес, хост може потрібно додати туди ще до того, як WordPress зможе під’єднатися. Без цього запит завершується помилкою ще до досягнення адресата. Жорстка помилка. Без часткового успіху.

8. Безпечно відкочуйте або вимикайте проксі

Відкат має бути передбачуваним. Видаліть константи проксі або значення змінних середовища, очистіть будь-які поля проксі в плагінах і перезавантажте WordPress. Робіть це в режимі обслуговування, якщо сайт отримує трафік. Потім переконайтеся, що сайт може звертатися до тих самих віддалених сервісів напряму.

Після видалення знову перевірте ті самі дії, які тестували раніше: перевірки оновлень, API-запити, валідацію ліцензії та завантаження віддалених медіа. Якщо все працює без проксі, ви підтвердили, що WordPress повернувся до прямих з’єднань. Якщо якийсь сервіс і далі не працює, проксі, можливо, був лише частиною рішення, а за ним ховається ще одне мережеве обмеження.

Наостанок перегляньте всі тимчасові облікові дані, збережені в конфігурації або змінних середовища, і видаліть їх із хоста, якщо вони більше не потрібні. Так ви збережете акуратність налаштувань. А ще запобіжите випадковому повторному використанню старого проксі через пів року, що трапляється частіше, ніж команди готові визнати.