Edge-сервер — физический или виртуальный узел в сети, расположенный географически близко к конечным пользователям. Обрабатывает запросы локально, не направляя их на центральный origin-сервер. Снижает задержку (latency) и разгружает основную инфраструктуру.
Как работает
При обращении пользователя к сайту DNS-резолвер определяет ближайший edge-сервер через Anycast-маршрутизацию или GeoDNS. Запрос уходит на этот узел, а не на origin. Если контент закеширован — edge отвечает немедленно. Если нет — запрашивает у origin, кеширует и отдаёт клиенту.
Edge-серверы образуют сеть CDN (Content Delivery Network). Akamai управляет более чем 4000 edge-узлов, Cloudflare — более 300. Selectel CDN размещает edge в российских городах и за рубежом.
История
Концепция edge-серверов появилась в 1998 году с запуском Akamai. MIT-стартап предложил кешировать контент ближе к пользователям после перегрузок интернет-магистралей во время трансляций крупных событий. Термин «edge computing» вышел за рамки CDN в 2010-х: теперь на edge-узлах выполняется код — AWS Lambda@Edge (2017), Cloudflare Workers (2017), Vercel Edge Functions.
Edge Computing vs CDN Edge
CDN edge кеширует статический контент: HTML, CSS, JS, медиафайлы. Edge Computing запускает код: авторизация, A/B-тестирование, персонализация, геолокация. Cloudflare Workers позволяет модифицировать HTTP-запросы и ответы на edge без обращения к origin — задержка ответа <10 мс вместо 50-200 мс от центрального сервера.
Edge vs Origin
| Критерий | Edge-сервер | Origin-сервер |
|---|---|---|
| Расположение | Сотни точек по миру | Один или несколько ЦОД |
| Функция | Кеш, прокси, вычисления | Основная бизнес-логика, БД |
| Задержка | 5-30 мс до пользователя | 50-300 мс |
| Масштабирование | Автоматическое | Требует настройки |
Применение для хостинга
Для WordPress и CMS: статика (изображения, CSS, JS) отдаётся с edge, динамика (PHP, БД) — с origin. Плагины WP Super Cache и W3 Total Cache интегрируются с CDN для автоматической разгрузки статики. Для VPS с Nginx: настройка Cache-Control заголовков определяет, что edge кеширует и как долго.
На что обращать внимание
Кеширование динамических страниц может показывать устаревший контент. Настройте исключения: страницы корзины, личного кабинета, admin-панель — не должны кешироваться. TTFB с edge снижается, но первый запрос к некешированному контенту (cache miss) может быть медленнее из-за дополнительного хопа через edge-сервер на origin.
Мониторинг edge-производительности
Инструменты для анализа edge-сети: Pingdom и GTmetrix измеряют время загрузки из разных точек мира. WebPageTest показывает waterfall-диаграмму с временами DNS, TCP, TTFB для каждого ресурса. Cache hit ratio — ключевая метрика: соотношение запросов, обработанных edge из кеша, к общему числу. Хорошим считается 90%+ для статических ресурсов.
Заголовок ответа X-Cache: HIT или CF-Cache-Status: HIT (Cloudflare) подтверждает, что ответ пришёл из кеша edge-сервера. MISS означает запрос к origin. Высокая доля MISS при кажущейся настройке кеширования — признак проблем с Cache-Control заголовками или наличия cookie, отключающих кеш.
Для Nginx на origin-сервере: add_header X-Served-By $hostname; позволяет в заголовке ответа видеть, какой именно сервер обработал запрос — полезно при нескольких origin за reverse proxy.