Массив $_SERVER: заголовки, строка запроса и контекст PHP для бэкенда

Зачем это знать на «1С‑Битрикс»

Ядро и ваш код в /local обслуживают запросы через тот же PHP, что и любой самописный скрипт. Понимание $_SERVER экономит часы при отладке редиректов, канонических URL, HTTPS за прокси и кронов без полного контекста веб‑сервера.

Что лежит в $_SERVER

Это не «ещё один массив из формы», а снимок окружения SAPI на момент входа в PHP: строка запроса, путь к скрипту, часть переменных CGI, а также псевдопеременные, которые заполняет сам PHP (например, версия интерпретатора). Набор ключей зависит от SAPI (Apache module, FPM+Nginx, встроенный сервер, CLI) и конфигурации.

Заголовки запроса: префикс HTTP_

Заголовки вида Host, Referer, User-Agent в CGI/FPM обычно попадают в верхний регистр, с подстановкой дефиса на подчёркивание и префиксом HTTP_. Поэтому в классической шпаргалке фигурируют HTTP_HOST и HTTP_REFERER — это не «особые» поля PHP, а отражение заголовков HTTP. Поле Host может отсутствовать в устаревших конфигурациях: современные браузеры и нормальный виртуальный хостинг его всегда посылают.

Строка запроса, метод и URI

REQUEST_METHOD — GET, POST и т. д. QUERY_STRING — сырая часть после ? без декодирования. REQUEST_URI — путь и query, как пришёл от клиента (важно для канонизации и логирования). SCRIPT_NAME — логический путь к точке входа PHP; PHP_SELF иногда совпадает, но в зависимости от настроек и подстановки path info может вести себя менее предсказуемо — для построения ссылок предпочтительнее данные маршрутизации фреймворка или явные константы проекта.

DOCUMENT_ROOT и физический путь

DOCUMENT_ROOT — корень виртуального хоста на диске; Bitrix‑пролог выставляет $_SERVER['DOCUMENT_ROOT'] до подключения модулей — от этого отталкиваются подключения файлов в админке и публичной части. SCRIPT_FILENAME — полный путь к исполняемому файлу в ФС; удобно для диагностики «какой именно index.php отработал» на сервере с несколькими сайтами.

Адрес клиента и цепочка прокси

REMOTE_ADDR — IP, с которого веб‑сервер принял соединение: за балансировщиком это часто адрес прокси. Заголовки X-Forwarded-For, X-Real-IP и аналоги не аутентичны сами по себе: их может подставить клиент. Использовать их имеет смысл только после фильтрации на уровне nginx/Envoy/ingress «доверенных прокси» и согласованной политики. Для геозависимой логики и лимитов не стоит смешивать «сырой» REMOTE_ADDR и произвольные HTTP_X_* без модели доверия.

HTTPS, порт и схема

Признак шифрования может выглядеть как HTTPS=on, SERVER_PORT=443 или специальные заголовки на терминирующем TLS прокси. Разные хостинги заполняют набор по‑разному; универсальный совет — нормализовать схему в одном месте (инициализация ядра, конфиг nginx) и не размножать проверки по проекту.

CLI: другой мир

В консоли нет HTTP‑контекста: типичные HTTP_* отсутствуют, зато есть argv/argc у запуска из командной строки. Агенты и cron на Bitrix часто выполняют php -f ... — не ожидайте там валидного REQUEST_URI, если сами его не эмулируете для учебного теста.

Практический минимум для чеклиста

• Заголовок клиента → ключ HTTP_ИМЯ в верхнем регистре с подчёркиваниями.
• Канонический URL и роутинг — из согласованных полей URI, а не из догадок по PHP_SELF.
• IP пользователя за прокси — только вместе с доверенной конфигурацией фронта.
• Скрипты в CLI не перепутывать с веб‑входом: отдельные ветки инициализации.