WordPress мультисайт и прокси
WordPress Multisite — одна установка ядра, десятки или сотни сайтов на поддоменах и отдельных доменах. Агентства, хостинг-провайдеры и медиахолдинги используют эту схему для экономии на обслуживании. Но когда плагины на разных subsite ходят во внешние API — платёжные шлюзы, CRM, сервисы доставки — все запросы идут с одного IP сервера. Прокси помогают маршрутизировать исходящий трафик, тестировать geo-зависимые интеграции и не «сжигать» основной адрес хостинга.
Зачем прокси в Multisite
Geo-тестирование. Плагин доставки показывает разные тарифы для DE и PL — проверить это с сервера в США без прокси нельзя. Лимиты API. Внешний сервис ограничивает 1000 запросов в сутки с IP — распределите subsite по пулу адресов. Отладка webhooks. Staging-сайт на subsite должен имитировать клиента из целевого региона при callback-тестах.
Multisite не меняет архитектуру HTTP-клиента WordPress: фильтр pre_http_request и константы в wp-config.php работают так же, как на одиночной установке.
Настройка исходящих запросов
Стандартный способ — mu-plugin или snippet в functions.php активной темы сети:
Для HTTPS-прокси задайте WP_PROXY_HOST, WP_PROXY_PORT, при необходимости WP_PROXY_USERNAME и WP_PROXY_PASSWORD. WordPress автоматически проксирует вызовы wp_remote_get() и wp_remote_post(). Для SOCKS5 понадобится обёртка через cURL — см. гайд по PHP cURL.
На тарифах NEONPROXY HTTPS и SOCKS5 доступны на одном адресе; выбор протокола зависит от того, поддерживает ли конкретный плагин SOCKS напрямую. Сравнение — в статье SOCKS5 vs HTTPS.
Изоляция subsite
Если разным сайтам сети нужны разные исходящие IP — например, white-label клиенты с отдельными CRM — логику прокси привязывают к get_current_blog_id(). Один subsite → один приватный IPv4 из пула. Shared-адреса допустимы только для dev-окружений.
Cron Multisite (wp-cron или системный cron с --url) наследует те же настройки прокси. Проверьте, что фоновые задачи не создают burst-нагрузку: внешний API может заблокировать весь пул.
WP-CLI и CI/CD
При деплое через GitHub Actions runner часто имеет датацентровый IP, который блокируют staging-API клиента. Передайте переменные окружения HTTP_PROXY и HTTPS_PROXY в job — WP-CLI и Composer подхватят их для исходящих запросов. Перед релизом прогоните адрес через чекер.
Multisite и внешние CDN
Исходящие запросы WordPress — не путать с входящими через Cloudflare. Прокси на сервере влияет только на то, как ваш PHP ходит наружу: к Mailchimp, Stripe, MaxMind GeoIP update. Если subsite отдаёт статику через CDN, проверка «как видит пользователь из DE» делается прокси на машине QA, а не на origin.
Плагины типа WP Remote Manage или MainWP инициируют исходящие connection к hub — при жёстком firewall хостинга hub может не достучаться до child site; прокси здесь не поможет, нужен inbound allowlist. Зато исходящие health-check с child на внешний мониторинг (UptimeRobot) через прокси имитируют точку проверки из другого региона.
Типичные ошибки
Глобальный прокси для всей сети, когда нужна точечная маршрутизация. Игнорирование таймаутов — медленный прокси блокирует wp-cron и замедляет админку. Хранение credentials прокси в публичном репозитории темы. Смешение production и staging subsite на одном исходящем IP при тестах платёжных интеграций.
Для нагрузочных сценариев смотрите также материал про load testing через прокси. Не забывайте про DNS-утечки на сервере: wp_remote_get может резолвить DNS локально, раскрывая real IP origin при некоторых конфигурациях.
Безопасность credentials
Не храните PROXY credentials в wp_options без encryption — любой SQL injection их раскроет. Используйте environment variables через .env на сервере или secrets manager хостинга. Для Multisite network admin — capability check: только super admin видит proxy settings в mu-plugin.
Логируйте исходящие ошибки wp_remote_* с proxy_id, но не password. При 407 Proxy Auth Required — ротация credentials через API, не hardcode в коде темы клиента.
Безопасность credentials
Не храните PROXY credentials в wp_options без encryption — любой SQL injection их раскроет. Используйте environment variables через .env на сервере или secrets manager хостинга. Для Multisite network admin — capability check: только super admin видит proxy settings в mu-plugin.
Логируйте исходящие ошибки wp_remote_* с proxy_id, но не password. При 407 Proxy Auth Required — ротация credentials через API, не hardcode в коде темы клиента.
Hosting и исходящие лимиты
Shared hosting часто блокирует исход outgoing connections на port 3128 — уточните у провайдера до покупки прокси. VPS с полным outbound — предпочтительнее для Multisite с тяжёлыми sync plugins. Rate limit исходящих с одного server IP к API Mailchimp — прокси распределяет subsite campaigns.