# enterno.io — Полная документация

> Enterno.io — бесплатная онлайн-платформа для мониторинга, анализа и диагностики сайтов.
> Проверка HTTP-заголовков, DNS-записей, SSL/TLS-сертификатов, ping и портов,
> IP-геолокация, анализ PageSpeed, массовая проверка и комплексная оценка здоровья сайта.

## Инструменты

### Проверка HTTP-заголовков
- URL: https://enterno.io/
- API: https://enterno.io/api/check.php
Отправляет HTTP-запросы к любому URL и показывает все заголовки ответа. Поддерживает методы GET, HEAD, POST. Показывает цепочки редиректов, время ответа, анализзаголовков безопасности. Доступны кастомные заголовки и пресеты User-Agent.

### DNS Lookup
- URL: https://enterno.io/dns
- API: https://enterno.io/api/dns.php
Запрос DNS-записей для любого домена. Поддерживает типы A, AAAA, MX, NS, TXT, CNAME, SOA. Показывает TTL, приоритет (для MX) и полные данные SOA.

### SSL/TLS Checker
- URL: https://enterno.io/ssl
- API: https://enterno.io/api/ssl.php
Проверка SSL/TLS-сертификатов. Показывает данные сертификата (CN, SAN, издатель, даты), информацию о соединении (протокол, шифр, биты), цепочку сертификатов. Определяетпросроченные, истекающие и несовпадающие сертификаты.

### Ping & порты
- URL: https://enterno.io/ping
- API: https://enterno.io/api/ping.php
ICMP-пинг со статистикой (мин/сред/макс задержка, потери пакетов). TCP-сканирование портов для популярных сервисов (HTTP, HTTPS, SSH, FTP, SMTP, DNS, MySQL, PostgreSQL идр.).

### IP геолокация
- URL: https://enterno.io/ip
- API: https://enterno.io/api/ip.php
Определение географического расположения по IP-адресу или имени хоста. Показывает страну, регион, город, провайдера, организацию, AS, часовой пояс, координаты.Поддерживает IPv4 и IPv6.

### PageSpeed анализ
- URL: https://enterno.io/speed
- API: https://enterno.io/api/pagespeed.php
Анализ производительности страницы через Google PageSpeed Insights API. Показывает Core Web Vitals (LCP, FID, CLS, FCP, TTFB), оценку производительности, возможностиоптимизации и диагностику.

### Health Score
- URL: https://enterno.io/health
- API: https://enterno.io/api/health-score.php
Комплексный анализ здоровья сайта. Оценивает заголовки безопасности, конфигурацию SSL/TLS, производительность и лучшие практики. Выставляет оценку от A+ до F с подробнымирекомендациями.

### WHOIS
- URL: https://enterno.io/whois
Информация о регистрации домена: регистратор, дата создания, дата истечения, NS-серверы, данные о владельце. Поддерживает все основные доменные зоны.

### Безопасность
- URL: https://enterno.io/security
Анализ заголовков безопасности (CSP, HSTS, X-Frame-Options и др.), проверка на типичные уязвимости и ошибки конфигурации. Оценка безопасности и рекомендации поисправлению.

### Traceroute
- URL: https://enterno.io/traceroute
Трассировка сетевого пути от наших серверов до любого хоста. Показывает каждый узел с IP-адресом, именем хоста и временем ответа. Полезно для диагностики сетевыхмаршрутов.

### Расширенная HTTP-проверка
- URL: https://enterno.io/advanced
Глубокий HTTP-анализ с кастомными методами (GET, POST, HEAD, PUT, DELETE), заголовками, телом запроса и настройками редиректов. Показывает сырые данные запроса иответа.

## REST API

- Base URL: https://enterno.io/api/
- Documentation: https://enterno.io/api/docs
- Authentication: API key via X-API-Key header
- Response format: JSON with {status, data, error} structure
- Rate limits: Free 50/day, Starter 500/day, Pro 5000/day, Business 50000/day

### Эндпоинты API
- POST /api/check.php — HTTP header check
- POST /api/dns.php — DNS lookup
- POST /api/ssl.php — SSL/TLS check
- POST /api/ping.php — Ping and port scan
- POST /api/ip.php — IP geolocation
- POST /api/pagespeed.php — PageSpeed analysis
- POST /api/health-score.php — Health score
- GET /api/tips.php?tool={tool} — Check tips/tooltips

## Справочник подсказок

### HTTP Подсказки

**Strict-Transport-Security** (`strict-transport-security`)
HSTS — защищает от атак понижения протокола, заставляя браузер всегда использовать HTTPS.
Fix: Добавьте: Strict-Transport-Security: max-age=31536000; includeSubDomains

**Content-Security-Policy** (`content-security-policy`)
Мощная защита от XSS и инъекций. Определяет разрешённые источники загрузки ресурсов.
Fix: Начните с: Content-Security-Policy: default-src 'self'

**Content-Type** (`content-type`)
Указывает MIME-тип и кодировку ответа. Позволяет браузеру правильно интерпретировать содержимое.

**Cache-Control** (`cache-control`)
Управляет кешированием ответа в браузере и прокси. Ключевой заголовок для производительности.

**Location** (`location`)
Используется при перенаправлении (3xx). Указывает URL, на который нужно перейти.

**X-Frame-Options** (`x-frame-options`)
Защита от clickjacking — запрещает встраивание страницы в iframe на других сайтах.
Fix: Добавьте: X-Frame-Options: SAMEORIGIN

**X-Content-Type-Options** (`x-content-type-options`)
Предотвращает MIME-sniffing. Браузер использует указанный Content-Type без «угадывания».
Fix: Добавьте: X-Content-Type-Options: nosniff

**Content-Encoding** (`content-encoding`)
Указывает алгоритм сжатия (gzip, br, deflate). Уменьшает объём передаваемых данных.

**Set-Cookie** (`set-cookie`)
Устанавливает cookie. Важно проверить флаги безопасности: Secure, HttpOnly, SameSite.
Fix: Добавьте флаги: Secure; HttpOnly; SameSite=Lax

**Content-Length** (`content-length`)
Указывает размер тела ответа в байтах. Помогает клиенту определить прогресс загрузки.

**X-Powered-By** (`x-powered-by`)
Раскрывает технологию серверной части (PHP, ASP.NET и т.д.). Рекомендуется удалить.
Fix: Удалите в PHP: header_remove('X-Powered-By') или expose_php = Off в php.ini

**Referrer-Policy** (`referrer-policy`)
Контролирует передачу информации о URL-источнике при переходах между страницами.
Fix: Рекомендуется: Referrer-Policy: strict-origin-when-cross-origin

**Permissions-Policy** (`permissions-policy`)
Ограничивает доступ к API браузера (камера, микрофон, геолокация и др.).
Fix: Добавьте: Permissions-Policy: camera=(), microphone=(), geolocation=()

**Server** (`server`)
Показывает тип и версию веб-сервера. Рекомендуется скрывать для безопасности.
Fix: Скройте версию: nginx — server_tokens off; Apache — ServerTokens Prod

**ETag** (`etag`)
Идентификатор версии ресурса для условного кеширования. Уменьшает трафик при повторных запросах.

**Vary** (`vary`)
Указывает, от каких заголовков запроса зависит ответ. Важен для корректного кеширования.

**Expires** (`expires`)
Устаревший способ управления кешем. Cache-Control имеет приоритет.

### HEALTH Подсказки

**HSTS (Strict-Transport-Security)** (`hsts`)
Заголовок HSTS заставляет браузер использовать только HTTPS-соединение с сайтом, защищая от атак понижения протокола и перехвата cookie.
Fix: Добавьте заголовок: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

**Валидный сертификат** (`valid-certificate`)
Проверяет, что SSL-сертификат выдан доверенным центром сертификации и не отозван.
Fix: Убедитесь, что используете сертификат от доверенного CA (Let's Encrypt, Comodo и др.)

**Content-Security-Policy** (`csp`)
CSP ограничивает источники загрузки скриптов, стилей и других ресурсов, защищая от XSS-атак и инъекций кода.
Fix: Настройте CSP с минимальными разрешениями: Content-Security-Policy: default-src 'self'; script-src 'self'

**Совпадение имени хоста** (`hostname-match`)
Проверяет, что доменное имя сайта совпадает с именем в SSL-сертификате (CN или SAN).
Fix: Перевыпустите сертификат с правильным доменным именем или добавьте домен в SAN

**X-Content-Type-Options** (`x-content-type-options`)
Предотвращает MIME-sniffing — браузер не будет «угадывать» тип контента, что защищает от XSS через подмену типа файла.
Fix: Добавьте заголовок: X-Content-Type-Options: nosniff

**Срок действия сертификата** (`certificate-expiry`)
Проверяет, что сертификат не просрочен и не истечёт в ближайшие дни.
Fix: Настройте автообновление сертификата через certbot или аналогичный инструмент

**HTTP статус** (`http-status`)
Проверяет, что сервер возвращает корректный HTTP-код ответа (2xx для успешных запросов).
Fix: Убедитесь, что страница доступна и возвращает HTTP 200

**X-Frame-Options** (`x-frame-options`)
Защищает от clickjacking-атак, запрещая встраивание вашего сайта в iframe на чужих доменах.
Fix: Добавьте заголовок: X-Frame-Options: SAMEORIGIN

**Версия TLS** (`tls-version`)
Проверяет, что сервер поддерживает современные версии TLS (1.2+). Старые версии (SSL 3.0, TLS 1.0/1.1) уязвимы.
Fix: Отключите TLS 1.0 и 1.1 в конфигурации веб-сервера, оставьте TLS 1.2 и 1.3

**Редирект на HTTPS** (`https-redirect`)
Проверяет, что HTTP-запросы автоматически перенаправляются на HTTPS с кодом 301.
Fix: Настройте 301-редирект с HTTP на HTTPS в конфигурации веб-сервера

**Referrer-Policy** (`referrer-policy`)
Контролирует, какая информация о URL передаётся при переходе на другой сайт. Защищает конфиденциальные данные в URL.
Fix: Добавьте заголовок: Referrer-Policy: strict-origin-when-cross-origin

**Время ответа** (`response-time`)
Измеряет время от запроса до получения первого байта ответа (TTFB). Быстрый ответ важен для UX и SEO.
Fix: Оптимизируйте серверную часть: включите кеширование, используйте CDN, оптимизируйте запросы к БД

**Отсутствие mixed content** (`no-mixed-content`)
Проверяет, что HTTPS-страница не загружает ресурсы по незащищённому HTTP, что нарушает безопасность.
Fix: Замените все HTTP-ссылки на HTTPS или используйте protocol-relative URL (//)

**Permissions-Policy** (`permissions-policy`)
Позволяет ограничить доступ к API браузера (камера, микрофон, геолокация) для вашего сайта и встроенных iframe.
Fix: Добавьте заголовок: Permissions-Policy: camera=(), microphone=(), geolocation=()

**Сжатие (gzip/brotli)** (`compression`)
Проверяет, включено ли сжатие ответов. Gzip/Brotli уменьшает размер передаваемых данных на 60-80%.
Fix: Включите gzip или brotli в настройках веб-сервера (nginx: gzip on; gzip_types text/html text/css application/javascript)

**HTTP/2** (`http2`)
HTTP/2 значительно ускоряет загрузку благодаря мультиплексированию, сжатию заголовков и server push.
Fix: Включите HTTP/2 в настройках веб-сервера (nginx: listen 443 ssl http2)

**Cross-Origin-Opener-Policy** (`coop`)
COOP изолирует контекст окна, предотвращая атаки через window.opener и обеспечивая process isolation.
Fix: Добавьте заголовок: Cross-Origin-Opener-Policy: same-origin

**Заголовки кеширования** (`caching-headers`)
Проверяет наличие Cache-Control/Expires заголовков для эффективного кеширования ресурсов в браузере.
Fix: Добавьте Cache-Control: public, max-age=31536000 для статических ресурсов

**Content-Type** (`content-type`)
Проверяет, что сервер указывает правильный MIME-тип и кодировку в заголовке Content-Type.
Fix: Убедитесь, что сервер отдаёт: Content-Type: text/html; charset=utf-8

**X-XSS-Protection** (`x-xss-protection`)
Устаревший заголовок для встроенного XSS-фильтра браузера. Современные браузеры используют CSP вместо него.
Fix: Рекомендуется: X-XSS-Protection: 0 (и использовать CSP вместо этого)

**Скрытие информации о сервере** (`server-info-hidden`)
Проверяет, что сервер не раскрывает свою версию и технологии через заголовки Server и X-Powered-By.
Fix: Уберите заголовки Server и X-Powered-By в настройках веб-сервера (nginx: server_tokens off)

### DNS Подсказки

**A-запись** (`a`)
Связывает доменное имя с IPv4-адресом сервера. Основная запись для работы веб-сайта.

**MX-запись** (`mx`)
Указывает почтовый сервер, обрабатывающий email для домена. Приоритет определяет порядок использования.

**NS-запись** (`ns`)
Указывает DNS-серверы, ответственные за зону домена. Критически важна для работы DNS.

**AAAA-запись** (`aaaa`)
Связывает доменное имя с IPv6-адресом. Обеспечивает доступность сайта по протоколу IPv6.

**TXT-запись** (`txt`)
Текстовые данные: SPF (защита от спуфинга email), DKIM, DMARC, верификация домена.

**CNAME-запись** (`cname`)
Алиас — перенаправляет один домен на другой. Нельзя использовать для корневого домена.

**SOA-запись** (`soa`)
Start of Authority — содержит информацию о зоне: первичный NS, email администратора, серийный номер, таймеры.

### SSL Подсказки

**Валидность сертификата** (`valid-certificate`)
Проверяет, что сертификат выдан доверенным CA, не отозван и цепочка доверия корректна.
Fix: Используйте сертификат от Let's Encrypt или другого доверенного CA

**Совпадение домена** (`hostname-match`)
Common Name или SAN сертификата должны совпадать с доменом сайта.
Fix: Перевыпустите сертификат с правильным доменным именем

**Срок действия** (`expiry`)
Истекший сертификат вызывает предупреждение в браузере и потерю доверия пользователей.
Fix: Настройте автоматическое обновление через certbot: certbot renew --dry-run

**Протокол TLS** (`protocol`)
TLS 1.2 и 1.3 считаются безопасными. Старые версии уязвимы к атакам (POODLE, BEAST).
Fix: Включите TLS 1.2/1.3, отключите SSL 3.0, TLS 1.0 и 1.1

**Набор шифров** (`cipher`)
Определяет алгоритмы шифрования. Слабые шифры (RC4, DES, 3DES) небезопасны.
Fix: Используйте рекомендованные Mozilla конфигурации: ssl-config.mozilla.org

**Цепочка сертификатов** (`chain`)
Полная цепочка от leaf до root CA должна быть установлена на сервере.
Fix: Убедитесь, что промежуточные сертификаты установлены: ssllabs.com/ssltest

**Subject Alternative Names** (`san`)
Список доменов, для которых действует сертификат. Wildcard (*.domain.com) покрывает поддомены.

### PING Подсказки

**Что такое время отклика** (`rtt`)
Ping RTT — время прохождения пакета до сервера и обратно. Нормальное значение: до 100 мс в пределах региона.

**Хост недоступен (100% потерь)** (`unreachable`)
Сервер не отвечает на ICMP. Причины: firewall блокирует ping, сервер выключен, проблема маршрутизации.
Fix: Проверьте, не блокирует ли firewall ICMP. Используйте TCP-мониторинг как альтернативу.

**Потеря пакетов** (`packet_loss`)
Потеря >1% пакетов сигнализирует о нестабильности соединения. Это влияет на VoIP, стриминг и онлайн-игры.

**Высокий ping (>200 мс)** (`high_latency`)
Высокая задержка — признак удалённости сервера, перегрузки сети или сложной маршрутизации через несколько хопов.
Fix: Рассмотрите CDN или выбор датацентра ближе к аудитории.

### IP Подсказки

**IP в чёрном списке** (`blacklist`)
Если IP в спам-листах (Spamhaus, SURBL), ваши письма попадают в спам, а трафик может блокироваться.
Fix: Проверьте репутацию через MXToolbox. Подайте запрос на удаление из блэклиста.

**PTR-запись (rDNS)** (`ptr_record`)
Обратная DNS-запись важна для почтовых серверов. Её отсутствие снижает доставляемость писем.

**Геолокация IP** (`geolocation`)
IP-адрес определяет физическое расположение сервера. GeoIP-базы могут иметь погрешность — реальное положение может отличаться на 50–200 км.

**Shared vs Dedicated IP** (`shared_ip`)
На shared-хостинге один IP используется тысячами сайтов. Проблемы соседей могут влиять на вашу репутацию.
Fix: Для серьёзных проектов рекомендуется выделенный IP.

### SPEED Подсказки

**Медленная загрузка (>3 сек)** (`slow_load`)
Время загрузки >3 секунд увеличивает отказы на 32% (Google). Критично для конверсии и позиций в поиске.
Fix: Сожмите изображения, включите кэширование, используйте CDN.

**TTFB > 600 мс** (`ttfb`)
Time To First Byte >600 мс — медленный сервер, тяжёлые SQL-запросы или отсутствие серверного кэша.
Fix: Включите Redis/Memcached, оптимизируйте SQL-запросы.

**Core Web Vitals** (`core_vitals`)
Google учитывает LCP, INP и CLS в ранжировании. LCP <2.5 сек, CLS <0.1 — целевые значения для хорошего опыта.

**Большой вес страницы (>2 МБ)** (`page_weight`)
Тяжёлые страницы медленно загружаются на мобильных с медленным интернетом.
Fix: Используйте WebP/AVIF, откладывайте загрузку некритических JS.

### SPAM Подсказки

**IP в критических блэклистах** (`listed_critical`)
Ваш IP найден в Spamhaus SBL, XBL или PBL — это серьёзные блэклисты, которые используют крупные почтовые провайдеры. Письма будут блокироваться.
Fix: Немедленно проверьте причину и подайте запрос на удаление через сайт Spamhaus.

**Отсутствует PTR-запись** (`rdns_missing`)
Почтовые серверы часто отклоняют письма с IP без обратной DNS-записи (PTR/rDNS).
Fix: Добавьте PTR-запись у вашего провайдера, указывающую на hostname сервера.

**IP в дополнительных блэклистах** (`listed_warning`)
Ваш IP найден в менее критичных базах данных. Влияние на доставку писем умеренное, но требует внимания.
Fix: Подайте запрос на удаление в соответствующий блэклист.

**IP чист** (`clean`)
IP-адрес не найден в проверяемых DNSBL. Это означает хорошую репутацию для отправки писем.

### HEADERS Подсказки

**Отсутствует HSTS** (`no_hsts`)
Без заголовка Strict-Transport-Security браузеры не принудительно используют HTTPS. Это риск SSL-stripping атак.
Fix: Добавьте: Strict-Transport-Security: max-age=31536000; includeSubDomains

**Длинная цепочка редиректов** (`redirect_chain`)
Каждый дополнительный редирект добавляет 100–300 мс к загрузке страницы.
Fix: Сократите цепочку редиректов до 1 перехода. Прямо с HTTP на HTTPS на финальный URL.

**Отсутствует Content-Security-Policy** (`no_csp`)
CSP защищает от XSS-атак, указывая разрешённые источники контента.
Fix: Настройте CSP заголовок под ваш сайт. Начните с режима report-only для отладки.

**Нет управления кэшем** (`no_cache`)
Без Cache-Control браузеры и CDN могут кэшировать ресурсы непредсказуемо.
Fix: Установите Cache-Control: max-age=3600 для статики, no-store для динамики.

### TRACEROUTE Подсказки

**Высокая задержка на хопе** (`high_latency`)
Резкий рост RTT на конкретном узле указывает на перегруженный канал или географически удалённый датацентр.
Fix: Проверьте географическое расположение проблемного узла через базу GeoIP.

**Много хопов (>15)** (`high_hops`)
Большое количество узлов в маршруте увеличивает задержку и риск потери пакетов на каком-либо участке.
Fix: Рассмотрите использование CDN для сокращения сетевого пути до пользователей.

**Таймаут на промежуточном узле** (`timeout_hop`)
Звёздочки (*) означают, что узел не отвечает на ICMP. Это нормально для firewall-защищённых роутеров.

**Асимметричный маршрут** (`asymmetric`)
Путь туда и обратно может проходить через разные узлы. Это нормально для интернет-маршрутизации.

### WHOIS Подсказки

**Домен истекает менее чем через 30 дней** (`expiring_soon`)
Если вы не продлите домен, он освободится и может быть зарегистрирован конкурентами или сквоттерами.
Fix: Продлите домен немедленно через вашего регистратора.

**Устаревшие NS-серверы** (`old_ns`)
NS-серверы домена не обновлялись более 5 лет. Убедитесь, что серверы актуальны.
Fix: Обновите NS-записи у регистратора, если сменили DNS-провайдера.

**Домен заблокирован (transferLock)** (`registrar_lock`)
Статус clientTransferProhibited защищает домен от несанкционированного переноса.

**Privacy Protection включён** (`privacy_on`)
Контактные данные владельца скрыты через WHOIS Privacy. Это нормально для личных сайтов.

### REDIRECTS Подсказки

**Обнаружена петля редиректов** (`redirect_loop`)
Два или более URL ссылаются друг на друга, создавая бесконечный цикл. Браузер отобразит ошибку ERR_TOO_MANY_REDIRECTS.
Fix: Проверьте настройки сервера и CMS. Убедитесь, что HTTPS-редирект настроен только в одном месте.

**Слишком много редиректов (>3)** (`too_many`)
Каждый лишний редирект замедляет загрузку и может негативно влиять на SEO.
Fix: Оптимизируйте до одного редиректа: HTTP → HTTPS → финальный URL.

**Используется 302 вместо 301** (`302_not_301`)
Временный редирект (302) не передаёт PageRank. Если редирект постоянный — используйте 301.
Fix: Замените 302 на 301 для постоянных редиректов.

**Редиректы настроены правильно** (`ok`)
Цепочка редиректов короткая и использует правильные коды статусов.

### SECURITY Подсказки

**Слабый SSL/TLS протокол** (`ssl_weak`)
Сервер поддерживает устаревшие версии TLS (1.0 или 1.1). Они уязвимы и отключены в современных браузерах.
Fix: Отключите TLS 1.0/1.1 в конфигурации nginx/Apache. Используйте TLS 1.2+ с ECDHE шифрами.

**Отсутствуют заголовки безопасности** (`missing_headers`)
Критически важные HTTP-заголовки безопасности не найдены: X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
Fix: Добавьте в nginx: add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff;

**Открыты потенциально опасные порты** (`open_ports`)
Обнаружены открытые порты, которые не должны быть публично доступны (напр. 3306, 5432, 6379).
Fix: Закройте административные порты с помощью firewall. Разрешите доступ только с доверенных IP.

**Базовые проверки пройдены** (`good`)
Основные настройки безопасности в порядке.

### SEO-AUDIT Подсказки

**Отсутствует тег <title>** (`no_title`)
Тег title — один из важнейших SEO-факторов. Без него поисковики не понимают тему страницы.
Fix: Добавьте уникальный title длиной 50–60 символов на каждую страницу.

**Отсутствует тег H1** (`no_h1`)
H1 — главный заголовок страницы. Его отсутствие ухудшает понимание структуры контента поисковиком.
Fix: Добавьте один тег H1 с основным ключевым словом страницы.

**Отсутствует meta description** (`no_meta_desc`)
Meta description влияет на кликабельность в выдаче (CTR). Без неё Google может сгенерировать описание из контента страницы.
Fix: Напишите уникальный meta description 120–160 символов с ключевым словом.

**Проблема с canonical URL** (`canonical`)
Некорректный или отсутствующий canonical может вызвать проблемы с дублями страниц.
Fix: Убедитесь, что rel=canonical указывает на основную версию URL.

### KEYWORDS Подсказки

**Плотность ключевых слов** (`keyword_density`)
Оптимальная плотность ключевого слова — 1–3% от общего объёма текста. Слишком низкая плотность снижает релевантность, слишком высокая сигнализирует о переоптимизации (keyword stuffing).
Fix: Используйте ключевое слово естественно, 1–2 раза на 100 слов. Варьируйте формы и добавляйте LSI-слова.

**Ключевое слово в title** (`title_keyword`)
Наличие ключевого слова в теге <title> — один из сильнейших сигналов релевантности для поисковых систем. Размещайте главное ключевое слово ближе к началу заголовка.
Fix: Добавьте целевое ключевое слово в начало тега <title>. Длина title: 50–60 символов.

**Ключевое слово в H1** (`h1_keyword`)
H1 — самый важный заголовок страницы. Поисковик ожидает увидеть главное ключевое слово в H1. Отсутствие ключевого слова снижает релевантность страницы.
Fix: Убедитесь, что H1 содержит целевое ключевое слово. На странице должен быть ровно один H1.

**Ключевое слово в мета-описании** (`meta_description_keyword`)
Google выделяет жирным ключевые слова в сниппете поиска, если они совпадают с запросом. Наличие ключевого слова в meta description увеличивает CTR из поиска.
Fix: Включите ключевое слово естественно в meta description. Длина: 120–160 символов.

**Ключевое слово в URL** (`url_keyword`)
URL является фактором ранжирования. Короткий, читаемый URL с ключевым словом улучшает релевантность и повышает CTR — пользователи видят URL в результатах поиска.
Fix: Используйте ключевое слово в slug URL. Разделяйте слова дефисами, избегайте параметров и ID.

**Ключевое слово в первом абзаце** (`keyword_in_first_paragraph`)
Размещение ключевого слова в первых 100 словах текста — сильный сигнал релевантности. Поисковики придают больший вес тексту, расположенному в начале страницы.
Fix: Упомяните ключевое слово в первом абзаце. Избегайте искусственного введения — текст должен оставаться читабельным.

**Вариации и LSI-слова** (`keyword_variations`)
Использование синонимов, словоформ и тематически связанных слов (LSI) помогает странице охватить больше поисковых запросов. Google понимает семантические связи между словами.
Fix: Добавьте LSI-слова и синонимы ключевого слова. Инструменты: Google Search Console, Яндекс.Вордстат.

**Ключевое слово в alt-тексте изображений** (`image_alt_keyword`)
Alt-текст описывает изображение для поисковых систем и пользователей с ограниченными возможностями. Включение ключевого слова в alt улучшает релевантность страницы и видимость в Google Images.
Fix: Добавьте описательный alt-текст с ключевым словом к основным изображениям. Не злоупотребляйте — alt должен описывать изображение.

### BROKEN-LINKS Подсказки

**Ссылка ведёт на страницу 404** (`http_404`)
Внутренние ссылки на несуществующие страницы (404) ухудшают пользовательский опыт и приводят к потере «ссылочного веса» (PageRank). Поисковики фиксируют такие ссылки при обходе сайта.
Fix: Обновите или удалите ссылки, ведущие на 404. Настройте 301-редиректы со старых URL на актуальные страницы.

**Цепочка редиректов** (`redirect_chain`)
Цепочка из 3 и более последовательных редиректов замедляет загрузку страницы и «размывает» ссылочный вес. Каждый дополнительный редирект добавляет задержку ~100–300 мс.
Fix: Настройте прямой редирект с исходного URL на конечный, минуя промежуточные шаги. Максимум — 1 редирект.

**Внешняя ссылка недоступна** (`external_404`)
Ссылки на внешние ресурсы, которые вернули 404, 410 или 5xx, снижают доверие к вашему сайту. Поисковики могут расценить такие ссылки как некачественный контент.
Fix: Замените неработающие внешние ссылки на актуальные ресурсы или удалите их. Используйте Wayback Machine для поиска архивных версий.

**Ссылка не отвечает (таймаут)** (`timeout`)
Ссылки, по которым сервер не отвечает в течение установленного времени, негативно влияют на время обхода и ухудшают пользовательский опыт — пользователь получает зависающую страницу.
Fix: Проверьте доступность целевого сервера. Если ресурс временно недоступен — уберите ссылку или замените на кэшированную версию.

**HTTP-ссылка на HTTPS-сайте** (`mixed_content_link`)
Ссылки на HTTP-ресурсы с HTTPS-страницы вызывают предупреждения о смешанном контенте. Браузеры блокируют загрузку HTTP-ресурсов на защищённых страницах.
Fix: Замените все HTTP-ссылки на HTTPS-версии. Проверьте абсолютные URL в базе данных и шаблонах.

**Якорная ссылка ведёт в никуда** (`anchor_missing`)
Ссылка с якорем (#section) ведёт на несуществующий элемент страницы. Пользователь переходит на страницу, но не попадает в нужное место.
Fix: Убедитесь, что элемент с указанным id существует на целевой странице. Проверьте правильность написания якоря.

**Непоследовательное использование www** (`www_non_www`)
Ссылки на www.example.com и example.com без настроенного редиректа ведут на дублирующиеся страницы. Это размывает ссылочный вес и может привести к индексации дублей.
Fix: Определите каноническую версию (с www или без) и настройте 301-редирект. Добавьте canonical-тег на все страницы.

**Ссылка с javascript:** (`javascript_link`)
Ссылки вида href="javascript:void(0)" или href="#" без обработчика не предоставляют поисковым системам никакого целевого URL. Это ухудшает обходимость и доступность.
Fix: Используйте реальные URL в href. Для интерактивных элементов — кнопки (<button>) вместо ссылок (<a>).

### PERFORMANCE Подсказки

**LCP — Largest Contentful Paint** (`lcp`)
LCP измеряет время отрисовки наибольшего видимого элемента страницы (изображение, видео или блок текста). Хорошее значение — до 2.5 с. Входит в Core Web Vitals Google.
Fix: Оптимизируйте изображения (WebP, lazy load для изображений ниже сгиба). Используйте CDN и предзагрузку ресурсов (rel="preload").

**CLS — Cumulative Layout Shift** (`cls`)
CLS измеряет визуальную стабильность страницы — насколько элементы сдвигаются при загрузке. Хорошее значение — менее 0.1. Высокий CLS возникает из-за изображений без указанных размеров или динамически вставляемого контента.
Fix: Всегда указывайте атрибуты width и height для изображений. Резервируйте место для рекламных блоков и шрифтов (font-display: optional).

**INP — Interaction to Next Paint** (`fid_inp`)
INP заменил FID в Core Web Vitals с марта 2024 года. Он измеряет задержку реакции страницы на все пользовательские взаимодействия (клик, нажатие клавиши, касание). Хорошее значение — до 200 мс.
Fix: Разбейте длинные задачи JavaScript (Long Tasks) на части. Используйте Web Workers для тяжёлых вычислений. Отложите загрузку неиспользуемого JS.

**TTFB — Time to First Byte** (`ttfb`)
TTFB — время от отправки запроса до получения первого байта ответа. Включает DNS-резолюцию, TCP-соединение, TLS-рукопожатие и время обработки на сервере. Хорошее значение — до 800 мс.
Fix: Используйте Redis/Memcached для кэширования серверного вывода. Оптимизируйте медленные SQL-запросы. Рассмотрите CDN для статического контента.

**Блокирующие рендер ресурсы** (`render_blocking`)
CSS и JavaScript, загружаемые синхронно в <head>, блокируют отрисовку страницы. Браузер ждёт их загрузки перед построением DOM, что увеличивает воспринимаемое время загрузки.
Fix: Добавьте defer или async для JS-скриптов. Выделите критический CSS inline. Перенесите некритичный CSS в конец страницы или используйте media-атрибут.

**Неоптимизированные изображения** (`image_optimization`)
Изображения — часто самый тяжёлый ресурс страницы. Несжатые PNG/JPEG или изображения с разрешением, превышающим необходимое, замедляют загрузку и увеличивают трафик.
Fix: Конвертируйте изображения в WebP или AVIF. Используйте сжатие (TinyPNG, Squoosh). Укажите srcset для адаптивных изображений. Добавьте loading="lazy" для изображений ниже сгиба.

**Неиспользуемый JavaScript** (`unused_js`)
Неиспользуемый JS-код загружается, парсится и компилируется браузером, тратя ресурсы CPU и замедляя интерактивность страницы. Google Lighthouse выявляет такие скрипты.
Fix: Используйте code splitting (динамический import()). Анализируйте bundle с помощью webpack-bundle-analyzer. Удалите или замените тяжёлые зависимости лёгкими альтернативами.

**Отсутствие или короткое время кэширования** (`cache_policy`)
Статические ресурсы без заголовка Cache-Control загружаются заново при каждом посещении. Это увеличивает нагрузку на сервер и замедляет повторные посещения.
Fix: Установите Cache-Control: max-age=31536000, immutable для версионированных ресурсов (CSS, JS, изображения). Для HTML используйте no-cache или короткое время кэширования.

### CRON-TESTER Подсказки

**Неверный синтаксис cron-выражения** (`invalid_syntax`)
Cron-выражение состоит из 5 полей: минуты (0-59), часы (0-23), дни месяца (1-31), месяцы (1-12), дни недели (0-7). Неверный синтаксис приводит к тому, что задание не запускается.
Fix: Проверьте каждое поле на допустимые значения. Используйте * для любого значения, */n для шага, a-b для диапазона, a,b для перечисления.

**Слишком частый запуск задания** (`too_frequent`)
Задания, запускаемые каждую минуту (*/1), создают высокую нагрузку на сервер, если выполнение занимает более минуты. Параллельные запуски могут исчерпать ресурсы.
Fix: Добавьте флаг блокировки (flock) для предотвращения параллельного запуска. Убедитесь, что задание завершается быстрее своего интервала.

**Часовой пояс cron** (`timezone`)
Cron работает в системном часовом поясе сервера. Если сервер в UTC, а вы ожидаете запуск по московскому времени, задание будет запускаться на 3 часа позже.
Fix: Проверьте часовой пояс командой timedatectl. При необходимости добавьте CRON_TZ=Europe/Moscow в начало crontab.

**Конфликт дней месяца и недели** (`day_overlap`)
Когда оба поля "день месяца" и "день недели" заданы (не *), cron запустит задание при выполнении ЛЮБОГО из условий (логическое ИЛИ), а не обоих одновременно. Это частая ошибка.
Fix: Если нужно запускать задание в первый понедельник месяца, используйте скрипт-оболочку с проверкой даты, а не только cron-выражение.

**Последний день месяца** (`last_day`)
Стандартный cron не поддерживает спецификатор L (последний день) как в некоторых расширенных планировщиках. Указание 28-31 * * запустит задание в каждый из этих дней.
Fix: Создайте скрипт-оболочку с проверкой: date -d tomorrow +%d | grep -q 01 && /path/to/script. Запускайте через cron каждый день: 0 23 * * *

**Вывод задания не перенаправлен** (`output_redirect`)
Если вывод cron-задания не перенаправлен, он отправляется на почту пользователя или теряется. Ошибки остаются незамеченными, что затрудняет диагностику.
Fix: Перенаправьте stdout и stderr в лог-файл: * * * * * /path/to/script >> /var/log/cron_job.log 2>&1. Настройте ротацию логов через logrotate.

**Проблемы с PATH в cron** (`env_path`)
Cron запускает задания с минимальным окружением — переменная PATH значительно урезана по сравнению с интерактивной сессией. Команды, доступные в терминале, могут быть недоступны в cron.
Fix: Укажите полный путь к исполняемым файлам: /usr/bin/php вместо php. Или задайте PATH явно в начале crontab: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

**Символ % в cron-выражении** (`percent_sign`)
Символ % в crontab имеет специальное значение: он интерпретируется как перенос строки. Команды с форматом даты типа date +%Y-%m-%d завершатся с ошибкой, если % не экранирован.
Fix: Экранируйте символ % обратным слешем в crontab: date +\%Y-\%m-\%d. Или вынесите команду в отдельный скрипт, где % работает нормально.

### FORMATTER Подсказки

**Невалидный JSON** (`json_invalid`)
JSON требует строгого соблюдения синтаксиса: ключи только в двойных кавычках, числа без ведущих нулей, запятые между элементами (но не после последнего). Одна ошибка делает весь документ невалидным.
Fix: Используйте JSON-валидатор для поиска ошибки. Частые проблемы: trailing comma, одинарные кавычки, отсутствие кавычек у ключей, комментарии (JSON не поддерживает комментарии).

**Невалидный XML** (`xml_invalid`)
XML требует корректного закрытия всех тегов, правильной вложенности и валидного DOCTYPE. Незакрытые теги или неэкранированные спецсимволы делают документ непригодным для парсинга.
Fix: Убедитесь, что все теги закрыты. Спецсимволы замените сущностями: &amp; &lt; &gt; &quot;. Проверьте корректность объявления кодировки.

**Непоследовательные отступы** (`indentation`)
Смешивание табуляции и пробелов, или разный размер отступов в одном файле — источник трудноуловимых ошибок в Python и YAML. В других языках это затрудняет читаемость и code review.
Fix: Настройте EditorConfig (.editorconfig) для унификации отступов в команде. Используйте Prettier или autopep8 для автоматического форматирования.

**Пробелы в конце строк** (`trailing_whitespace`)
Пробелы в конце строк (trailing whitespace) засоряют git diff, нарушают некоторые парсеры и являются признаком небрежного кода. В Markdown они могут нечаянно создавать принудительные переносы строк.
Fix: Настройте редактор на автоматическое удаление trailing whitespace при сохранении. В VSCode: "files.trimTrailingWhitespace": true.

**Слишком длинные строки** (`line_length`)
Строки длиннее 80-120 символов затрудняют чтение кода в терминале, при code review на GitHub и работе с разделёнными окнами. PEP 8 рекомендует 79 символов для Python.
Fix: Переносите длинные строки по логическим точкам разрыва. Используйте линтеры (ESLint max-len, pylint line-too-long) для автоматической проверки.

**Проблема с кодировкой файла** (`encoding`)
Файлы не в UTF-8 могут вызывать непредсказуемые ошибки на разных системах: неправильное отображение символов, ошибки парсинга или сломанные строковые операции в коде.
Fix: Конвертируйте файл в UTF-8 без BOM (Byte Order Mark). В VSCode измените кодировку через Change File Encoding в строке состояния.

**Нет переноса строки в конце файла** (`missing_newline_eof`)
POSIX-стандарт требует, чтобы текстовые файлы заканчивались символом перевода строки. Отсутствие newline в конце файла может вызывать предупреждения компиляторов и проблемы при конкатенации файлов.
Fix: Добавьте пустую строку в конец файла. В VSCode настройте: "files.insertFinalNewline": true.

**Дублирующиеся ключи в JSON/YAML** (`duplicate_keys`)
Дублирование ключей в JSON или YAML является ошибкой (RFC 8259 запрещает дубли). Поведение парсеров непредсказуемо: некоторые берут первое значение, другие последнее, третьи выбрасывают исключение.
Fix: Найдите и удалите дублирующиеся ключи. Используйте jq для JSON: jq "." file.json — он предупредит о дублях. Для YAML используйте yamllint.

### ROBOTS-CHECKER Подсказки

**Запрещён весь сайт (Disallow: /)** (`disallow_all`)
Директива Disallow: / для Googlebot или * полностью закрывает сайт от индексации. Это критическая ошибка, которая оставляет сайт невидимым в поиске.
Fix: Удалите или исправьте правило Disallow: /. Если закрытие временное — поставьте задачу для снятия блокировки после завершения работ.

**Sitemap не указан в robots.txt** (`sitemap_missing`)
Добавление строки Sitemap: https://example.com/sitemap.xml помогает поисковикам быстрее найти и обойти все страницы. Без этой директивы обнаружение sitemap полностью зависит от Search Console.
Fix: Добавьте в robots.txt строку: Sitemap: https://your-domain.com/sitemap.xml. Убедитесь, что URL sitemap указан абсолютным.

**Заблокированы CSS и JavaScript** (`disallow_css_js`)
Блокировка CSS и JS файлов мешает Googlebot правильно отрисовать страницы. Google не может оценить внешний вид страницы, если не загружаются стили и скрипты.
Fix: Разрешите Googlebot доступ к CSS и JS файлам. Используйте Google Search Console — инструмент Проверка URL — для проверки рендеринга.

**Правило для всех роботов (*)** (`user_agent_wildcard`)
User-agent: * применяется ко всем роботам, для которых нет отдельного блока. Специфичные блоки (User-agent: Googlebot) имеют приоритет над * для соответствующего робота.
Fix: Создайте отдельный блок User-agent: Googlebot для настроек, специфичных для Google. Перечисляйте нежелательных роботов явно, а не через * Disallow: /.

**Директива Crawl-delay** (`crawl_delay`)
Crawl-delay устанавливает минимальный интервал между запросами робота в секундах. Google игнорирует эту директиву (используйте настройки скорости обхода в Search Console). Яндекс и Bing её поддерживают.
Fix: Для управления скоростью обхода Googlebot используйте Google Search Console. Для остальных роботов значение Crawl-delay от 1 до 10 допустимо.

**Порядок Allow и Disallow** (`allow_disallow_order`)
Когда URL соответствует нескольким правилам, большинство роботов выбирают наиболее конкретное (длинное) правило. При одинаковой длине — первое встретившееся правило.
Fix: Размещайте более специфичные Allow-правила перед общими Disallow-правилами. Тестируйте robots.txt в инструментах Google Search Console и Яндекс.Вебмастер.

**Путаница с noindex в robots.txt** (`noindex_robots`)
robots.txt не поддерживает директиву noindex. Это распространённое заблуждение. Для запрета индексации страницы используйте мета-тег robots content="noindex" или заголовок X-Robots-Tag.
Fix: Для страниц: добавьте <meta name="robots" content="noindex"> в HTML. Для файлов (PDF, изображений): используйте HTTP-заголовок X-Robots-Tag: noindex.

**BOM в начале robots.txt** (`encoding_bom`)
Если robots.txt сохранён с BOM (Byte Order Mark) в UTF-8, некоторые роботы не распознают первую строку как директиву и игнорируют весь файл. BOM — невидимые байты EF BB BF в начале файла.
Fix: Пересохраните robots.txt как UTF-8 без BOM. Проверьте командой: head -c 3 robots.txt | xxd — не должно быть ef bb bf.

### PROTOCOL-TEST Подсказки

**HTTPS не включён** (`no_https`)
Сайт без HTTPS передаёт данные пользователей в открытом виде. Браузеры Chrome и Firefox показывают предупреждение "Небезопасно". Google использует HTTPS как фактор ранжирования с 2014 года.
Fix: Получите SSL-сертификат (Let's Encrypt — бесплатно). Настройте 301-редирект с HTTP на HTTPS. Обновите все внутренние ссылки и ресурсы на HTTPS.

**HTTP/2 не поддерживается** (`http2_missing`)
HTTP/2 значительно быстрее HTTP/1.1 за счёт мультиплексирования, сжатия заголовков и серверного push. Его отсутствие замедляет загрузку страниц с множеством ресурсов.
Fix: Включите HTTP/2 в конфигурации nginx: listen 443 ssl http2; или Apache: Protocols h2 http/1.1. Требует действующего SSL-сертификата.

**Устаревшая версия TLS** (`tls_old_version`)
TLS 1.0 и TLS 1.1 признаны устаревшими и небезопасными (RFC 8996). Они уязвимы для атак POODLE, BEAST и FREAK. Все современные браузеры отключили их поддержку.
Fix: Отключите TLS 1.0 и 1.1. В nginx: ssl_protocols TLSv1.2 TLSv1.3; В Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

**Слабые шифры TLS** (`weak_cipher`)
Устаревшие шифровальные наборы (RC4, DES, 3DES, NULL cipher) делают соединение уязвимым для криптографических атак. PCI DSS и NIST требуют использования только сильных шифров.
Fix: Настройте только современные cipher suites. Используйте Mozilla SSL Config Generator для получения готовых конфигураций nginx/Apache.

**Отсутствует заголовок HSTS** (`hsts_missing`)
HSTS (HTTP Strict Transport Security) принуждает браузер всегда использовать HTTPS для данного домена. Без HSTS первый запрос к сайту по HTTP уязвим для SSL-stripping атак.
Fix: Добавьте заголовок: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. После проверки добавьте домен в HSTS Preload List на hstspreload.org.

**Несоответствие сертификата домену** (`cert_mismatch`)
SSL-сертификат выдан на другой домен или не охватывает текущий поддомен. Браузеры показывают критическое предупреждение безопасности, большинство пользователей покидают такие сайты.
Fix: Проверьте Subject Alternative Names (SAN) в сертификате. Получите wildcard-сертификат (*.example.com) или добавьте нужный домен в SAN при перевыпуске.

**HTTP/3 (QUIC) недоступен** (`http3_quic`)
HTTP/3 использует протокол QUIC на базе UDP вместо TCP, что уменьшает задержки при нестабильном соединении (мобильный интернет). Chrome и Firefox поддерживают HTTP/3 по умолчанию.
Fix: Для включения HTTP/3 в nginx требуется версия 1.25+ с поддержкой QUIC. Добавьте listen 443 quic reuseport; и заголовок alt-svc для оповещения браузеров. Требует открытого UDP 443.

**HTTP не перенаправляется на HTTPS** (`redirect_http_https`)
Если сайт доступен по HTTP и HTTPS без редиректа, поисковики видят дублирующийся контент. Пользователи могут случайно использовать незащищённую версию.
Fix: Настройте 301-редирект с http:// на https:// на уровне сервера. В nginx: return 301 https://$host$request_uri; Проверьте, что не создаётся цепочка редиректов.

### ABUSE Подсказки

**IP в чёрном списке** (`in_blacklist`)
IP-адрес, занесённый в чёрные списки (DNSBL, Spamhaus, AbuseIPDB), приводит к тому, что письма с этого адреса блокируются почтовыми серверами, а трафик может фильтроваться CDN и WAF. Это прямо влияет на доставляемость email и репутацию домена.
Fix: Запросите удаление (delisting) через форму соответствующего блок-листа. Устраните причину — вредоносную активность, открытый relay или скомпрометированный сервер. Проверьте все IP своего диапазона.

**Высокий spam score** (`spam_score`)
Spam score показывает вероятность того, что IP или домен используется для рассылки спама. Высокое значение (обычно выше 5 из 10) означает, что письма с этого источника будут часто попадать в папку «Спам» или блокироваться.
Fix: Настройте SPF, DKIM и DMARC для своего домена. Не отправляйте письма незаинтересованным получателям. Мониторьте жалобы через Google Postmaster Tools и Postmark Spam Complaints.

**Открытый прокси** (`open_proxy`)
Открытый прокси-сервер позволяет любому пользователю пропускать трафик через ваш IP, что приводит к злоупотреблениям. Это одна из основных причин попадания в чёрные списки. ISP и хостинг-провайдеры могут заблокировать такой сервер.
Fix: Закройте прокси-порты (3128, 8080, 1080) в брандмауэре или настройте аутентификацию. Используйте iptables или firewalld для ограничения доступа. Проверьте все открытые порты с помощью nmap.

**IP является выходным узлом Tor** (`tor_exit_node`)
Выходные узлы сети Tor используются анонимными пользователями, включая злоумышленников. Многие сервисы блокируют трафик с Tor-узлов. Если ваш сервер является exit-нодой Tor, он с высокой вероятностью занесён в базы блокировок.
Fix: Если сервер непреднамеренно стал Tor exit-нодой, удалите программное обеспечение Tor. Свяжитесь с хостинг-провайдером. Подайте заявку на исключение из Tor exit-списков.

**Зарегистрированы жалобы на злоупотребления** (`abuse_reports`)
AbuseIPDB и аналогичные сервисы собирают жалобы от пользователей и автоматизированных систем о вредоносной активности с конкретного IP. Большое количество жалоб снижает репутацию IP и влечёт блокировки.
Fix: Изучите отчёты о жалобах в AbuseIPDB. Определите причину — сканирование портов, брутфорс, DDoS или отправку спама. Примите меры: установите fail2ban, ограничьте исходящий трафик.

**IP принадлежит дата-центру** (`datacenter_ip`)
IP-адреса из ASN дата-центров (AWS, DigitalOcean, Hetzner) часто блокируются сервисами, защищающимися от ботов и автоматизированных атак. Это влияет на доставляемость email и доступ к некоторым платформам.
Fix: Для массовых email-рассылок используйте выделенные email-сервисы (SendGrid, Mailgun, Amazon SES). Для web-сервисов рассмотрите использование жилых (residential) или ISP-прокси для критичных операций.

**Отсутствует обратная DNS-запись (PTR)** (`reverse_dns_missing`)
PTR-запись связывает IP-адрес с именем хоста. Её отсутствие является сигналом для спам-фильтров: большинство легитимных почтовых серверов имеют PTR-запись. Серверы без PTR часто блокируются на SMTP-уровне.
Fix: Обратитесь к своему хостинг-провайдеру или ISP для настройки PTR-записи. Она должна указывать на FQDN сервера (например, mail.example.com). Убедитесь, что прямая DNS-запись совпадает с PTR.

**История компрометации IP** (`compromised_history`)
Некоторые IP имеют историю использования в ботнетах, вредоносных кампаниях или для рассылки спама — даже если текущий владелец не причастен. Такая история сохраняется в базах данных репутации месяцами.
Fix: Проверьте историю в Spamhaus, Talos Intelligence и AbuseIPDB. Если IP «грязный», рассмотрите смену IP-адреса. При сохранении IP — активно запрашивайте delisting и демонстрируйте чистую активность.

### AI-CHECK Подсказки

**Высокая вероятность AI-генерации** (`high_ai_probability`)
Контент с высоким показателем AI-генерации (обычно >80%) может быть помечен поисковыми системами как некачественный или сгенерированный. Google обновил политику: «полезный контент для людей» важнее его происхождения, но сугубо машинный текст без добавленной ценности наказывается.
Fix: Добавьте уникальный человеческий опыт, примеры из практики и экспертные комментарии. Перепишите ключевые секции вручную. Убедитесь, что контент отвечает на реальные вопросы целевой аудитории.

**Низкая перплексия текста** (`perplexity_low`)
Перплексия (perplexity) измеряет непредсказуемость текста. Низкая перплексия означает, что текст очень предсказуем и однородён — типичный признак AI-генерации. Человеческий текст имеет более высокую вариативность и «буrstiness».
Fix: Варьируйте длину предложений, используйте разговорные обороты, идиомы и нестандартные формулировки. Добавляйте личные истории, цифры из реальных исследований и конкретные примеры.

**Низкий показатель burstiness** (`burstiness_low`)
Burstiness описывает неравномерность длин предложений в тексте. AI-модели склонны генерировать однородные предложения схожей длины. Человеческое письмо чередует короткие и длинные предложения, что создаёт ритм.
Fix: Сознательно чередуйте короткие и длинные предложения. Используйте односложные конструкции для акцента. Длинные предложения с несколькими мыслями — тоже нормально. Главное — разнообразие.

**Шаблонные AI-фразы** (`generic_phrases`)
AI-детекторы находят характерные фразы, часто генерируемые языковыми моделями: «в современном мире», «важно отметить», «в заключение хотелось бы сказать», «это позволяет» и подобные. Их концентрация повышает AI-score.
Fix: Замените шаблонные вводные фразы на конкретные утверждения. Начинайте абзацы с факта, цифры или вопроса, а не с общего вступления. Читайте текст вслух — AI-фразы режут слух.

**Слишком однородная структура** (`structure_uniformity`)
AI-сгенерированный контент часто имеет идеально симметричную структуру: одинаковые по размеру абзацы, строго три пункта в каждом списке, регулярные переходы. Это легко распознаётся детекторами.
Fix: Нарушайте симметрию намеренно: добавляйте параграфы разной длины, списки с разным числом пунктов, вставки цитат, врезки с предупреждениями. Реальный контент органичен, а не отформатирован «по шаблону».

**Риск фактических ошибок** (`factual_accuracy`)
AI-модели могут «галлюцинировать» — уверенно генерировать ложные факты, несуществующие исследования и неверную статистику. Такие ошибки не только снижают доверие, но и могут привести к юридическим рискам.
Fix: Проверяйте каждый факт, цифру и ссылку в AI-сгенерированном тексте. Используйте только первичные источники (научные статьи, официальная документация). Добавляйте ссылки на источники.

**Риск SEO-пессимизации** (`seo_spam_risk`)
Google Helpful Content Update (2022–2024) нацелен на выявление и пессимизацию контента, созданного «в первую очередь для поисковых систем». Массово генерированный AI-контент без редактуры попадает под действие этих обновлений.
Fix: Создавайте контент вокруг реального пользовательского запроса (search intent), а не ключевых слов. Показывайте E-E-A-T: экспертизу, опыт, авторитет и достоверность. Добавляйте авторство реального человека.

**Смешанный контент (AI + человек)** (`mixed_content`)
Частичная AI-генерация с последующей человеческой редактурой показывает более низкие AI-score и лучше воспринимается детекторами. Оптимальный подход: AI для черновика, человек — для редактуры и дополнения уникальным опытом.
Fix: Используйте AI как инструмент для ускорения работы, а не как замену писателя. Добавляйте личный взгляд, уникальные данные, кейсы из практики. Итоговый текст должен быть неотличим от написанного человеком.

### ASN Подсказки

**Репутация ASN** (`asn_reputation`)
Автономная система (AS) объединяет диапазоны IP-адресов под единым управлением. Репутация всего ASN влияет на каждый IP в его составе. ASN хостинг-провайдеров, замеченных в спам-рассылках, несут коллективную ответственность — их IP блокируются превентивно.
Fix: Выбирайте хостинг-провайдеров с хорошей репутацией ASN. Проверьте репутацию ASN своего провайдера в Talos Intelligence и Spamhaus ASN-reputation. Смените провайдера при необходимости.

**Диапазон IP из чёрного списка** (`ip_range_blacklisted`)
Если целый диапазон IP (например, /24 или /16) из вашего ASN занесён в чёрный список, все IP в этом диапазоне блокируются независимо от их индивидуальной активности. Это называется «block listing by subnet».
Fix: Проверьте все блок-листы на предмет блокировки вашей подсети. Обратитесь к провайдеру для получения IP из другого диапазона. При необходимости смените провайдера или используйте другой ASN.

**Несоответствие геолокации** (`geolocation_mismatch`)
Расхождение между физическим расположением сервера и геолокацией IP (по базам MaxMind, ip-api) может влиять на таргетирование рекламы, геоблокировки и работу CDN. Некоторые сервисы блокируют трафик из «неожиданных» регионов.
Fix: Обратитесь к хостинг-провайдеру для корректировки геолокационных данных. Используйте сервисы обновления геолокации MaxMind или IP2Location. Рассмотрите CDN с правильным геотаргетингом.

**Аномалии в BGP-маршрутизации** (`routing_anomaly`)
BGP (Border Gateway Protocol) управляет маршрутизацией трафика между автономными системами. BGP-перехваты (hijacking) и утечки маршрутов (route leaks) могут приводить к перенаправлению трафика через нежелательные AS. Это также индикатор нестабильности.
Fix: Мониторьте BGP-маршруты своего ASN через BGPmon или Cloudflare Radar. Внедрите RPKI (Resource Public Key Infrastructure) для верификации маршрутов. Свяжитесь с провайдером при обнаружении аномалий.

**Тип провайдера влияет на репутацию** (`hosting_provider_type`)
IP из ASN крупных облачных провайдеров (AWS, GCP, Azure) часто блокируются анти-ботовыми системами, так как большинство автоматизированных атак исходит именно оттуда. ISP-адреса имеют лучшую репутацию для email и менее склонны к блокировкам.
Fix: Для email-рассылок используйте специализированные ESP с выделенными IP. Для веб-сервисов — балансируйте между производительностью облака и репутацией ISP. Используйте residential IP для задач, требующих высокой репутации.

**Страна регистрации ASN** (`asn_country`)
Страна, в которой зарегистрирован ASN, влияет на юридическую ответственность, требования по хранению данных (GDPR, ФЗ-152) и геотаргетинг. Некоторые страны имеют плохую репутацию среди почтовых фильтров.
Fix: Выбирайте провайдеров, зарегистрированных в юрисдикциях, соответствующих вашим требованиям по защите данных. Для российской аудитории предпочтительны RU-провайдеры. Для международного охвата — нейтральные юрисдикции (NL, DE).

**Размер ASN и количество префиксов** (`prefix_count`)
Количество IP-префиксов в ASN отражает масштаб провайдера. Маленькие ASN с несколькими префиксами могут быть менее надёжными. Очень большие ASN (тысячи префиксов) с высокой вероятностью содержат «грязные» диапазоны.
Fix: При выборе провайдера проверяйте историю ASN через BGP.tools или RIPEstat. Средние по размеру ASN известных провайдеров обычно предпочтительнее. Мониторьте изменения префиксов своего ASN.

**Политика пиринга ASN** (`peering_policy`)
Политика пиринга определяет, с какими другими AS обменивается трафиком данная AS. Открытый пиринг (open peering) означает более широкий охват, но и меньший контроль. Закрытый пиринг (selective peering) — лучшая репутация и стабильность.
Fix: Уточните политику пиринга своего провайдера через PeeringDB. Для критичных сервисов выбирайте провайдеров с присутствием на крупных интернет-биржах (IXP): MSK-IX, DE-CIX, AMS-IX.

### HTTP-STATUS Подсказки

**Ошибка 404 — страница не найдена** (`404_not_found`)
404 означает, что запрошенный ресурс не существует на сервере. Внутренние ссылки на 404-страницы ухудшают UX и приводят к потере PageRank. Поисковики перестают посещать страницы, постоянно возвращающие 404.
Fix: Исправьте ссылки или настройте 301-редирект на актуальную страницу. Создайте информативную страницу 404 с навигацией. Настройте мониторинг 404 через Google Search Console.

**Ошибка 500 — внутренняя ошибка сервера** (`500_server_error`)
5xx-ошибки означают, что сервер не смог обработать запрос. Если ключевые страницы возвращают 500, поисковики временно исключают их из индекса. Длительные 500-ошибки приводят к постоянному исключению.
Fix: Проверьте логи сервера (/var/log/nginx/error.log, /var/log/apache2/error.log). Исправьте причину ошибки. Настройте мониторинг uptime для немедленного оповещения о 5xx.

**Постоянный редирект 301** (`301_redirect`)
301 означает, что ресурс permanently перемещён. Это правильный способ переноса страниц и домена. Поисковики передают ~90–99% «веса» через 301. Убедитесь, что цепочки редиректов отсутствуют.
Fix: Используйте 301 для постоянных перемещений страниц. Проверяйте отсутствие цепочек редиректов. Обновляйте внутренние ссылки напрямую на финальный URL, а не через редирект.

**Временный редирект 302** (`302_redirect`)
302 означает временное перемещение. Поисковики не передают PageRank через 302 в полном объёме и сохраняют исходный URL в индексе. Использование 302 вместо 301 при постоянном перемещении — типичная ошибка.
Fix: Замените 302 на 301 для постоянных редиректов. Используйте 302 только для действительно временных перенаправлений (A/B-тесты, техническое обслуживание). Проверьте все редиректы через инструменты SEO-аудита.

**Ошибка 403 — доступ запрещён** (`403_forbidden`)
403 означает, что сервер понял запрос, но отказывает в доступе. Причины: неверные права на файлы, IP-блокировка, WAF, или отсутствие аутентификации. Если публичные страницы возвращают 403 — они выпадают из индекса.
Fix: Проверьте права доступа к файлам (chmod) и конфигурацию веб-сервера. Убедитесь, что IP пользователя не заблокирован. Проверьте конфигурацию WAF / CloudFlare на предмет ложных срабатываний.

**Сервис недоступен 503** (`503_unavailable`)
503 означает, что сервер временно не может обработать запрос (перегрузка, техническое обслуживание). При правильном использовании с заголовком Retry-After поисковики возвращаются через указанное время. Без этого заголовка 503 может привести к деиндексации.
Fix: Добавьте заголовок Retry-After при плановом техобслуживании. Настройте автоматическое масштабирование или кэширование для предотвращения перегрузок. Используйте очереди запросов (rate limiting) для защиты от DDoS.

**Успешный ответ 200 OK** (`200_ok`)
200 OK — стандартный ответ при успешном запросе. Убедитесь, что мягкие 404-страницы (soft 404) не возвращают 200 вместо 404. Google может расценить страницу с текстом «Страница не найдена» и кодом 200 как дублированный тонкий контент.
Fix: Настройте правильные коды ответа для ошибочных состояний. Проверьте через Google Search Console наличие «мягких 404». Используйте инструменты crawl-аудита для выявления страниц с неверными кодами.

**CORS заголовки и статус ответа** (`cors_headers`)
Статус 200 при CORS-запросе не гарантирует успех операции — браузер может заблокировать ответ из-за отсутствия заголовка Access-Control-Allow-Origin. Неверная конфигурация CORS приводит к ошибкам в консоли браузера и нерабочим API-запросам.
Fix: Настройте заголовки CORS на сервере: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers. Используйте whitelist доменов вместо * для production-окружения.

### IP-CALC Подсказки

**Размер подсети и маска** (`subnet_size`)
Маска подсети определяет, сколько адресов входит в диапазон. /24 содержит 254 хоста, /16 — 65534. Правильный выбор маски предотвращает расточительное расходование IP-адресов или нехватку адресного пространства.
Fix: Используйте маски минимально необходимого размера. Для небольших сегментов — /29 (6 хостов) или /30 (2 хоста). Планируйте адресное пространство с учётом роста на 2–3 года вперёд.

**Частные и публичные IP-адреса** (`private_vs_public`)
RFC 1918 определяет три диапазона частных IP: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Эти адреса маршрутизируются только внутри локальных сетей. Публичные IP уникальны в интернете. Смешивание приводит к проблемам с маршрутизацией.
Fix: Используйте RFC 1918-адреса для внутренней инфраструктуры. Публичные IP — только для внешне доступных сервисов. Для доступа к внутренним ресурсам используйте VPN или NAT.

**Broadcast-адрес подсети** (`broadcast_address`)
Broadcast-адрес — последний адрес в подсети, используется для отправки пакета всем хостам сети. Его нельзя назначить хосту. В /24-сети с адресом 192.168.1.0 broadcast-адрес будет 192.168.1.255.
Fix: Не назначайте broadcast-адрес интерфейсу хоста. Учитывайте, что в каждой подсети два адреса «зарезервированы»: первый (network address) и последний (broadcast). Количество доступных хостов = 2^(32-маска) - 2.

**Поддержка IPv6** (`ipv6_support`)
Пул IPv4-адресов исчерпан. IPv6 предоставляет 2^128 адресов и устраняет потребность в NAT. Google индексирует IPv6-сайты. Отсутствие IPv6 может стать проблемой при работе с провайдерами, использующими только IPv6.
Fix: Включите двойной стек (dual stack): IPv4 + IPv6. Получите /48-блок IPv6 у провайдера. Настройте AAAA-записи DNS. Проверьте, что все сервисы работают через IPv6: nginx, Apache, MySQL bind.

**Перекрытие подсетей** (`subnetting_overlap`)
Перекрывающиеся подсети (например, 10.0.0.0/16 и 10.0.1.0/24) создают конфликты маршрутизации и непредсказуемое поведение сети. Это частая ошибка при проектировании сети для VPN или микросервисов.
Fix: Используйте инструмент расчёта подсетей перед проектированием сети. Ведите актуальную схему IP-адресации (IP Address Management, IPAM). Проверяйте таблицы маршрутизации после изменений.

**VLSM — маски переменной длины** (`vlsm_planning`)
VLSM (Variable Length Subnet Masking) позволяет использовать разные маски внутри одного адресного пространства, оптимизируя использование IP. Например: /30 для point-to-point соединений, /24 для офисных сегментов.
Fix: Планируйте VLSM от большего к меньшему: сначала выделяйте большие блоки, затем делите на меньшие. Инструменты: ipcalc, SolarWinds IP Address Manager. Документируйте назначение каждого диапазона.

**NAT и его ограничения** (`nat_considerations`)
NAT (Network Address Translation) позволяет нескольким устройствам совместно использовать один публичный IP, но нарушает принцип сквозной (end-to-end) маршрутизации. Это создаёт проблемы для VoIP, P2P, IPsec и некоторых игровых приложений.
Fix: Используйте NAT только при необходимости. Для проблемных протоколов настройте UPnP или port forwarding. При переходе на IPv6 NAT не нужен. Документируйте все NAT-правила и их назначение.

**Суперсети и агрегация маршрутов** (`supernetting`)
Суперсети (supernetting) объединяют несколько подсетей в один блок для упрощения таблиц маршрутизации. Например, 192.168.0.0/24 + 192.168.1.0/24 = 192.168.0.0/23. Это снижает нагрузку на маршрутизаторы.
Fix: Агрегируйте смежные подсети при анонсировании в BGP. Используйте суперсети в конфигурациях ACL и firewall для упрощения правил. Убедитесь, что суперсеть не охватывает лишние IP.

### MX-LOOKUP Подсказки

**Отсутствует MX-запись** (`no_mx_record`)
Если для домена не настроена MX-запись, он не может принимать электронную почту. Письма на такой домен будут отклоняться с ошибкой. Также это сигнал для спам-фильтров: домен без MX часто используется только для отправки спама.
Fix: Добавьте MX-запись в DNS-зону домена. Она должна указывать на ваш почтовый сервер (например, mail.example.com). Приоритет (priority) определяет порядок использования серверов при наличии нескольких MX.

**Приоритет MX-записей** (`mx_priority`)
Значение priority (предпочтение) в MX-записи определяет, какой сервер используется первым. Сервер с наименьшим приоритетом (меньшим числом) получает почту первым. При недоступности — следующий по приоритету. Наличие нескольких MX обеспечивает резервирование.
Fix: Настройте основной и резервный почтовые серверы с разными приоритетами (например, 10 и 20). Убедитесь, что оба сервера корректно принимают почту. Проверьте MX через dig mx example.com.

**SPF-запись не настроена** (`spf_record`)
SPF (Sender Policy Framework) указывает, какие серверы уполномочены отправлять почту от имени домена. Без SPF серверы-получатели не могут проверить подлинность отправителя — письма чаще попадают в спам или блокируются.
Fix: Добавьте TXT-запись SPF: v=spf1 include:_spf.google.com ~all (для Google Workspace) или v=spf1 mx -all (для собственного сервера). Используйте -all (hard fail) вместо ~all (soft fail) для строгой политики.

**DKIM не настроен** (`dkim_missing`)
DKIM (DomainKeys Identified Mail) добавляет цифровую подпись к исходящим письмам. Получатель проверяет подпись через DNS-запись. DKIM защищает от подделки отправителя и является обязательным требованием Google и Yahoo для массовых отправителей с 2024 года.
Fix: Включите DKIM в своём почтовом сервере или ESP. Добавьте DKIM TXT-запись в DNS (обычно вида: selector._domainkey.example.com). Используйте ключи длиной минимум 2048 бит.

**DMARC не настроен** (`dmarc_missing`)
DMARC (Domain-based Message Authentication, Reporting and Conformance) объединяет SPF и DKIM и указывает, что делать с письмами, не прошедшими проверку. Без DMARC злоумышленники могут отправлять письма от имени вашего домена.
Fix: Добавьте TXT-запись DMARC: _dmarc.example.com → v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. Начните с p=none (мониторинг), затем переходите к p=quarantine и p=reject.

**TTL MX-записей** (`mx_ttl`)
TTL (Time to Live) определяет, как долго другие серверы кэшируют ваши MX-записи. Слишком высокий TTL замедляет распространение изменений при смене почтового сервера. Слишком низкий — увеличивает нагрузку DNS.
Fix: Оптимальный TTL для MX-записей: 3600–14400 секунд (1–4 часа). Перед плановой миграцией почты снизьте TTL до 300 секунд за 24–48 часов. После завершения миграции верните стандартный TTL.

**A-запись для MX-хоста** (`mx_a_record`)
MX-запись должна указывать на имя хоста (не IP), а это имя хоста должно иметь A-запись (или AAAA для IPv6). Если A-запись для MX-хоста отсутствует или некорректна, почтовые серверы не смогут установить соединение.
Fix: Убедитесь, что имя хоста в MX-записи разрешается в корректный IP. Проверьте: dig A mail.example.com. MX не должен указывать на IP напрямую или на CNAME — только на A/AAAA-запись.

**Порты почтового сервера** (`mail_server_port`)
Почтовые серверы используют стандартные порты: 25 (SMTP между серверами), 587 (SMTP с аутентификацией, submission), 465 (SMTPS), 993 (IMAPS), 995 (POP3S). Заблокированные порты нарушают доставку почты.
Fix: Проверьте доступность портов почтового сервера: telnet mail.example.com 25. Порт 25 часто блокируется хостинг-провайдерами для исходящих соединений. Для отправки через ISP используйте порт 587.

### PORT-SCANNER Подсказки

**Открытые опасные порты** (`open_dangerous_ports`)
Открытые порты, не используемые публично (3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB), создают прямую угрозу безопасности. Их сканируют автоматические боты ежечасно. Взлом БД через открытый порт — наиболее частый вектор атаки на VPS.
Fix: Закройте все порты баз данных брандмауэром (iptables, ufw). Открывайте только 80, 443 и SSH (желательно нестандартный порт). Используйте SSH-туннели или VPN для доступа к внутренним сервисам.

**SSH на стандартном порту 22** (`ssh_default_port`)
SSH на порту 22 — первая цель брутфорс-атак. Серверы на стандартном порту получают тысячи попыток входа в сутки от автоматизированных ботов. Это засоряет логи и создаёт нагрузку на систему аутентификации.
Fix: Измените порт SSH на нестандартный (например, 2222, 22222). Настройте fail2ban для блокировки после нескольких неудачных попыток. Используйте только ключи SSH, отключив парольную аутентификацию (PasswordAuthentication no).

**Лишние открытые сервисы** (`unnecessary_services`)
Каждый запущенный и доступный сетевой сервис увеличивает поверхность атаки. Сервисы, которые не нужны для работы сайта (Telnet, FTP, rsyncd, сервисы печати), должны быть остановлены.
Fix: Проведите аудит запущенных сервисов: ss -tlnp. Остановите и отключите ненужные: systemctl stop <service> && systemctl disable <service>. Ограничьте доступ к оставшимся сервисам по IP через firewall.

**Политика брандмауэра** (`firewall_policy`)
Политика «deny all by default» (запрет всего по умолчанию) обеспечивает максимальную безопасность: открываются только явно разрешённые порты. Политика «allow all» с отдельными правилами запрета создаёт риск пропуска уязвимых сервисов.
Fix: Настройте iptables или ufw с политикой DROP по умолчанию: iptables -P INPUT DROP. Добавляйте разрешения явно: -A INPUT -p tcp --dport 443 -j ACCEPT. Используйте nftables для современных систем.

**Порт 443 и SSL-конфигурация** (`port_443_ssl`)
Открытый порт 443 без правильной SSL-конфигурации опаснее закрытого порта: пользователи думают, что соединение защищено, но используются слабые шифры или недействительный сертификат. Проверьте конфигурацию SSL отдельно.
Fix: Убедитесь, что на порту 443 установлен действующий SSL-сертификат. Отключите слабые шифры и устаревшие протоколы. Используйте Mozilla SSL Config Generator для генерации рекомендуемой конфигурации.

**UDP-порты и их риски** (`udp_ports`)
UDP-порты сложнее сканировать и часто остаются без внимания. Открытые UDP-порты (53 DNS, 161 SNMP, 123 NTP) могут использоваться для amplification DDoS-атак: злоумышленник подделывает источник запроса, и сервер отвечает жертве.
Fix: Закройте неиспользуемые UDP-порты. Для DNS-сервера ограничьте рекурсивные запросы по IP. Для NTP настройте ограничения: restrict -4 default kod notrap nomodify nopeer noquery. Проверьте через nmap -sU.

**Обнаружение сканирования портов** (`port_scan_detection`)
Активное сканирование портов — первый шаг при разведке перед атакой. Системы обнаружения вторжений (IDS) могут выявить и заблокировать сканеры до того, как они найдут уязвимые сервисы.
Fix: Установите и настройте fail2ban с jail для SSH, HTTP и других сервисов. Рассмотрите использование portknocking для скрытия SSH. Настройте iptables для обнаружения SYN-сканирований: -m recent --update --seconds 60 --hitcount 10.

**Раскрытие версий сервисов** (`service_version_exposure`)
Баннеры портов (ServerTokens, Server header, SSH banner) раскрывают версии ПО. Злоумышленник, зная версию, может найти известные CVE-уязвимости и использовать готовые эксплойты. Это называется version fingerprinting.
Fix: Скройте версии в ответах сервисов: nginx (server_tokens off), Apache (ServerTokens Prod, ServerSignature Off), SSH (Banner /dev/null). Регулярно обновляйте ПО для устранения известных уязвимостей.

### SCREENSHOT Подсказки

**Сломанная вёрстка** (`layout_broken`)
Визуальные дефекты на скриншоте — наложение элементов, выход контента за границы, неверное выравнивание — часто незаметны разработчикам, работающим в конкретном браузере. Скриншот из Headless Chrome позволяет увидеть реальную картину рендеринга.
Fix: Проверьте CSS grid и flexbox на отсутствие переполнений (overflow: hidden vs overflow: auto). Используйте CSS-переменные для отступов. Тестируйте на разных размерах экрана. Проверьте z-index конфликты.

**Контент above-the-fold** (`above_fold_content`)
Первый экран (above the fold) — наиболее важная область страницы. Пользователи принимают решение остаться или уйти в первые 3–5 секунд. Скриншот показывает, что видит пользователь сразу после загрузки, без скролла.
Fix: Убедитесь, что в верхней части страницы есть чёткий заголовок, ценностное предложение и призыв к действию (CTA). Избегайте огромных изображений-баннеров, скрывающих полезный контент. Проверьте LCP-элемент.

**Мобильный viewport** (`mobile_viewport`)
Google использует mobile-first indexing — сайт индексируется в мобильной версии. Скриншот в мобильном viewport (375x812) показывает, что видит типичный пользователь iPhone. Сломанная мобильная вёрстка напрямую влияет на ранжирование.
Fix: Убедитесь, что meta viewport установлен: <meta name="viewport" content="width=device-width, initial-scale=1">. Проверьте медиазапросы. Используйте относительные единицы (%, vw, rem) вместо фиксированных пикселей.

**Видимость CTA на скриншоте** (`cta_visibility`)
Кнопки призыва к действию (CTA) должны быть хорошо видны и контрастны на скриншоте. Плохой контраст, мелкий шрифт или расположение «ниже линии видимости» снижают конверсию. WCAG требует минимальный контраст 4.5:1 для текста.
Fix: Используйте контрастные цвета для CTA-кнопок. Размещайте основной CTA в верхней части страницы. Тестируйте контраст через WebAIM Contrast Checker. Убедитесь, что кнопки выглядят кликабельными.

**Проблемы с загрузкой шрифтов** (`font_loading`)
FOUT (Flash of Unstyled Text) и FOIT (Flash of Invisible Text) — визуальные артефакты при загрузке веб-шрифтов. На скриншоте они проявляются как системные шрифты вместо брендовых или полностью невидимый текст.
Fix: Используйте font-display: swap для предотвращения FOIT. Предзагружайте критичные шрифты: <link rel="preload" as="font">. Ограничьте количество начертаний (weight/style). Рассмотрите системные шрифты для основного текста.

**Загрузка изображений на скриншоте** (`image_loading`)
Скриншот может показывать незагруженные изображения (иконка "сломанного изображения") или заглушки вместо реального контента. Это происходит при проблемах с путями к файлам, CORS-ограничениях или медленной загрузке.
Fix: Проверьте правильность путей к изображениям (относительные vs абсолютные). Убедитесь, что CORS настроен для внешних изображений. Добавьте атрибут alt для всех изображений. Проверьте 404 в Network Tab DevTools.

**Использование whitespace** (`whitespace_usage`)
Whitespace (пустое пространство) — важный инструмент UI. Его избыток делает страницу пустой и незаконченной. Нехватка — перегруженной и нечитаемой. Скриншот позволяет оценить баланс визуальных элементов.
Fix: Убедитесь, что между секциями есть достаточно отступов (padding/margin). Используйте последовательную систему отступов (8px grid). Проверьте плотность контента — страница не должна выглядеть пустой или перегруженной.

**Предпросмотр в социальных сетях (OG)** (`social_meta_preview`)
Open Graph и Twitter Card мета-теги определяют, как страница выглядит при шаринге в соцсетях и мессенджерах. Скриншот og:image должен быть 1200×630 пикселей. Отсутствие og:image — серьёзный пробел в маркетинговой упаковке.
Fix: Добавьте og:image (1200×630), og:title, og:description в <head>. Создайте уникальные og:image для ключевых страниц. Проверьте предпросмотр через Facebook Sharing Debugger и Twitter Card Validator.

### TECH-DETECT Подсказки

**Версия CMS раскрыта** (`cms_version_exposed`)
Раскрытая версия CMS (WordPress, Joomla, Drupal) позволяет злоумышленнику найти известные уязвимости для конкретной версии и использовать готовые эксплойты. Особенно опасно для устаревших версий с известными CVE.
Fix: Скройте версию CMS: для WordPress удалите или переопределите функцию the_generator() и meta generator. Обновляйте CMS до последней версии. Отключите отображение версии в заголовках и RSS-лентах.

**Устаревшие JS-библиотеки** (`outdated_libraries`)
jQuery, Bootstrap, Lodash и другие библиотеки с известными уязвимостями, если они не обновлены, являются прямым вектором атаки. Ретродетекторы (Retire.js, Snyk) находят уязвимые версии по сигнатурам кода.
Fix: Обновите все JS-библиотеки до актуальных версий. Используйте npm audit или yarn audit для выявления уязвимостей. Настройте Dependabot или Renovate для автоматического обновления зависимостей.

**Раскрытие серверных технологий** (`server_tech_disclosure`)
Заголовки X-Powered-By (PHP/7.4, ASP.NET), Server (nginx/1.18.0, Apache/2.4.41), X-Generator раскрывают стек технологий. Это облегчает нацеленные атаки: злоумышленник знает, какие уязвимости искать.
Fix: Удалите заголовок X-Powered-By: expose_php = Off в php.ini. Для nginx: server_tokens off. Для Apache: ServerTokens Prod. Удалите X-Generator в CMS. Используйте Nikto для проверки раскрытых заголовков.

**Наличие WAF** (`waf_detected`)
WAF (Web Application Firewall) — Cloudflare, Sucuri, AWS WAF — добавляет слой защиты перед приложением. Его наличие видно через технологические отпечатки: специфические заголовки, cookies и страницы блокировки. WAF защищает от SQLi, XSS, CSRF и DDoS.
Fix: Настройте WAF перед продакшен-сервером. Cloudflare предлагает бесплатный WAF. Настройте правила для вашего приложения. Тестируйте WAF на ложные срабатывания перед включением строгого режима.

**Использование CDN** (`cdn_usage`)
CDN (Content Delivery Network) ускоряет доставку статических ресурсов, снижает задержку для географически удалённых пользователей и защищает от DDoS. Технодетектор определяет CDN по IP-диапазонам, заголовкам и DNS.
Fix: Используйте CDN для статических ресурсов: Cloudflare (бесплатно), CloudFront, BunnyCDN. Настройте правила кэширования (Cache-Control). Убедитесь, что CDN не кэширует API-ответы и личные данные.

**Стек аналитики** (`analytics_stack`)
Google Analytics, Яндекс.Метрика, Hotjar и другие аналитические инструменты видны технодетектором. Множество аналитических скриптов замедляет загрузку страниц и увеличивает время ожидания первого байта (TBT). Каждый скрипт добавляет ~50–200 мс.
Fix: Ограничьтесь минимально необходимым набором аналитики. Загружайте скрипты аналитики с атрибутом async или через GTM. Рассмотрите server-side аналитику (Plausible, Fathom) для минимального влияния на скорость.

**Платформа e-commerce** (`ecommerce_platform`)
Технологический стек e-commerce платформы (WooCommerce, Shopify, Magento) виден детекторам. Зная платформу, злоумышленники ищут специфические уязвимости. Shopify и Magento имеют богатую историю CVE-уязвимостей.
Fix: Обновляйте платформу и плагины. Используйте официальные плагины из проверенных источников. Регулярно сканируйте сайт на уязвимости (WPScan для WordPress). Настройте мониторинг безопасности.

**Отпечаток фреймворка** (`framework_fingerprint`)
React, Vue, Angular, Next.js оставляют характерные следы в HTML и JS: data-reactroot, __NEXT_DATA__, window.__vue__, специфические имена бандлов. Это нормально, но раскрывает стек для конкурентов и злоумышленников.
Fix: Для продакшена минифицируйте и обфусцируйте JS. Удалите development-атрибуты (data-reactroot). Настройте SRI (Subresource Integrity) для внешних ресурсов. Отключите source maps в продакшен-сборке.

### UPTIME-CALC Подсказки

**SLA 99.9% — что это означает** (`sla_99_9`)
SLA 99.9% ("три девятки") означает не более 8 часов 45 минут простоя в год. Это типичный уровень для managed-хостинга и небольших SaaS. Для критичных бизнес-систем этого может быть недостаточно — рассчитайте допустимый RTO (Recovery Time Objective).
Fix: Подпишитесь на SLA своего хостинг-провайдера. Настройте мониторинг uptime (UptimeRobot, Pingdom). Рассчитайте бизнес-потери за каждый час простоя и установите требуемый уровень SLA для своей системы.

**SLA 99.99% — четыре девятки** (`sla_99_99`)
SLA 99.99% допускает не более 52 минут 35 секунд простоя в год. Достижение этого уровня требует геораспределённой инфраструктуры, автоматического failover и активного мониторинга. Это уровень крупных банков и платёжных систем.
Fix: Внедрите multi-region deployment с автоматическим failover. Используйте load balancer с health checks. Настройте автоматические аварийные переключения. Проводите chaos engineering для проверки устойчивости системы.

**Плановое техническое обслуживание** (`planned_maintenance`)
Время планового обслуживания обычно вычитается из расчёта SLA при наличии соответствующего соглашения. Уведомляйте пользователей заранее через statuspage. Планируйте обслуживание в период минимальной нагрузки (ночь, выходные).
Fix: Настройте страницу статуса (Cachet, Statuspage.io). Уведомляйте пользователей через email и соцсети минимум за 24 часа. Проводите обслуживание в наименее нагруженное время. Минимизируйте окно обслуживания через blue-green deployment.

**MTTR — среднее время восстановления** (`mttr`)
MTTR (Mean Time To Recovery) — среднее время от возникновения инцидента до восстановления работы. Высокий MTTR означает длительные простои. Цель — минимальный MTTR через автоматизацию: auto-restart, auto-failover, runbooks.
Fix: Документируйте runbooks для типичных инцидентов. Настройте автоматический перезапуск сервисов (systemd RestartPolicy, Kubernetes). Регулярно проводите fire drills — учения по восстановлению. Измеряйте MTTR для каждого инцидента.

**Резервирование компонентов** (`redundancy`)
Single Point of Failure (SPOF) — единая точка отказа — означает, что выход из строя одного компонента роняет всю систему. Типичные SPOF: единственный сервер, один DNS, один ISP, один регион облака.
Fix: Аудит SPOF: составьте карту всех компонентов системы. Устраните SPOF поэтапно: начните с самых критичных. Добавьте резервный DNS-провайдер, failover-хост, резервный канал связи. Тестируйте failover регулярно.

**Мониторинг и оповещения** (`monitoring_alerting`)
Мониторинг без оповещений бесполезен — проблему обнаружат пользователи, а не команда. Средний бизнес узнаёт о простое через 20–30 минут без мониторинга. Каждая дополнительная минута простоя — потерянный доход и репутация.
Fix: Настройте мониторинг с интервалом проверки 1 минута (UptimeRobot бесплатно, Better Uptime). Настройте алерты в Telegram, Slack, PagerDuty. Мониторьте не только HTTP 200, но и время ответа, SSL-срок и критичные бизнес-метрики.

**RPO — цель по точке восстановления** (`backup_rpo`)
RPO (Recovery Point Objective) — максимально допустимая потеря данных при восстановлении после сбоя. RPO = 24 часа означает, что можно потерять данные за сутки. Для транзакционных систем RPO должен стремиться к 0.
Fix: Определите RPO для каждого типа данных. Настройте резервное копирование с частотой, соответствующей RPO. Для RPO < 1 часа используйте репликацию БД в реальном времени. Регулярно тестируйте восстановление из резервных копий.

**Страница статуса сервисов** (`status_page`)
Публичная страница статуса (status page) — важный инструмент коммуникации во время инцидентов. Она снижает нагрузку на поддержку: пользователи видят актуальный статус без обращения в support. Отсутствие statuspage усиливает тревогу пользователей.
Fix: Создайте публичную страницу статуса: Cachet (self-hosted), Statuspage.io или Instatus. Разместите её на отдельном домене или CDN (не на основном сервере). Обновляйте страницу в течение первых 5 минут после обнаружения инцидента.

## Возможности мониторинга

- Мониторинг HTTP/HTTPS доступности (интервал 1-60 мин)
- Мониторинг истечения SSL-сертификатов
- Мониторинг истечения доменов
- Каналы уведомлений: Email, Telegram, Slack, Discord, Webhooks
- Публичные статус-страницы с кастомными доменами
- Управление инцидентами с обновлениями
- Окна плановых работ

## Статьи

### [Слабые cipher suites: как найти и отключить небезопасные шифры TLS](https://enterno.io/articles/ssl-weak-cipher-suites)
Слабые cipher suites (RC4, 3DES, MD5, EXPORT) снижают оценку SSL Labs до B или F. Как проверить, отключить в nginx и выбрать безопасный набор.
Слабые cipher suites: как найти и отключить небезопасные шифры TLS
Cipher suite — набор криптографических алгоритмов, который клиент и сервер согласуют во время TLS-handshake: обмен ключами, аутентификация, симметричное шифрование, MAC. Устаревшие наборы (RC4, 3DES, EXPORT, NULL, MD5) снижают оценку SSL Labs до B или F, делают сайт уязвимым к атакам POODLE, BEAST, SWEET32, и являются провалом PCI DSS. Разберём, как найти слабые шифры и заменить их на современный safe-профиль.

Что такое «слабый»...

### [HSTS и HSTS Preload: полное руководство по принудительному HTTPS](https://enterno.io/articles/ssl-hsts-preload-guide)
HSTS и preload-лист — как заставить браузер всегда использовать HTTPS. Настройка Strict-Transport-Security, подача в hstspreload.org, подводные камни.
HSTS и HSTS Preload: полное руководство по принудительному HTTPS
HTTP Strict Transport Security (HSTS) — механизм безопасности, который говорит браузеру: «для этого домена всегда используй HTTPS, даже если пользователь набрал http://». Preload идёт дальше: ваш домен вшивается в браузеры до первой загрузки. Правильно настроенный HSTS защищает от MITM-атак на первом соединении, неправильно — блокирует сайт на месяцы. Разберём, как настроить безопасно.

Как работает HSTS
Сервер отдаёт заголовок Str...

### [Бесплатный SSL через Let's Encrypt: установка certbot за 10 минут](https://enterno.io/articles/ssl-free-letsencrypt-setup)
Бесплатный SSL-сертификат через Let's Encrypt и certbot: пошаговая установка на nginx, Apache, автообновление и подводные камни. Работает на любом Linux.
Бесплатный SSL через Let's Encrypt: установка certbot за 10 минут
Let's Encrypt — некоммерческий центр сертификации, выдающий бесплатные SSL-сертификаты с автоматическим обновлением. С 2016 года они стали де-факто стандартом для малого и среднего бизнеса: настройка занимает 10 минут, обновление происходит само, а сертификат доверяют все современные браузеры. В статье — полный гайд по установке certbot на Ubuntu/Debian и CentOS, с примерами для nginx и Apache.

Что такое Let's Encrypt и ACME-прот...

### [TLS 1.3 vs TLS 1.2: что изменилось и как правильно мигрировать](https://enterno.io/articles/ssl-tls-1-3-vs-1-2)
TLS 1.3 vs TLS 1.2 — подробное сравнение: скорость, безопасность, совместимость. Пошаговое руководство по миграции nginx и обратной совместимости.
TLS 1.3 vs TLS 1.2: что изменилось и как правильно мигрировать
TLS 1.3 вышел в 2018 году (RFC 8446) и в 2026-м используется на 90%+ HTTPS-трафика в интернете. Он существенно быстрее, безопаснее и проще TLS 1.2. Если ваш сайт всё ещё работает только на TLS 1.2 — это несколько сотен миллисекунд потерь на каждого пользователя и отставание от best practices. Разберём отличия, покажем миграцию и рассмотрим подводные камни обратной совместимости.

Ключевые отличия TLS 1.3 от TLS 1.2
1. Handshake в одн...

### [Неполная цепочка SSL-сертификата: как найти и исправить incomplete chain](https://enterno.io/articles/ssl-certificate-chain-incomplete)
Неполная цепочка SSL (incomplete chain) — причина ошибок у мобильных клиентов и API. Как собрать fullchain.pem, добавить intermediate и проверить цепочку.
Неполная цепочка SSL-сертификата: как найти и исправить incomplete chain
Incomplete certificate chain — это ситуация, когда сервер отдаёт только собственный листовой сертификат, без промежуточных (intermediate). Настольные браузеры часто умеют «дотягивать» цепочку из своего кеша, но мобильные клиенты, старые библиотеки, curl, Java-приложения и API-клиенты этого не делают — и отваливаются с ошибкой «unable to get local issuer certificate». В статье разберём, как диагностировать проблему и правиль...

### [Wildcard vs SAN-сертификат: когда какой выбрать в 2026](https://enterno.io/articles/ssl-wildcard-vs-san-certificate)
Wildcard vs SAN сертификат — разбор отличий, цены, безопасность и автоматизация. Какой тип сертификата выбрать для разных архитектур и сколько доменов покрыть.
Wildcard vs SAN-сертификат: когда какой выбрать в 2026
Wildcard и SAN (Subject Alternative Name) — два способа покрыть несколько доменов одним SSL-сертификатом. Выбор между ними влияет на стоимость, безопасность и простоту автоматизации. В этой статье разберём, чем они различаются, когда каждый из них уместен и почему для большинства современных проектов SAN-сертификат от Let's Encrypt выгоднее, чем платный wildcard.

Что такое wildcard-сертификат
Wildcard — это сертификат с маской *.example.com...

### [Self-signed certificate: когда использовать и как избежать предупреждений](https://enterno.io/articles/ssl-self-signed-certificate)
Self-signed SSL сертификат: зачем нужен, как создать через openssl, добавить в trust store и когда лучше использовать Let's Encrypt или внутреннюю PKI.
Self-signed certificate: когда использовать и как избежать предупреждений
Self-signed certificate — сертификат, подписанный не доверенным центром сертификации (CA), а собственным ключом владельца. Браузер его не принимает и показывает предупреждение ERR_CERT_AUTHORITY_INVALID. Тем не менее, self-signed остаётся нужной вещью во внутренних сетях, для разработки и для тестовых стендов. Разберём, как правильно создать такой сертификат, когда он уместен, и как избавить команду от постоянных предупреж...

### [Mixed Content: как найти и исправить HTTP-ресурсы на HTTPS-сайте](https://enterno.io/articles/ssl-mixed-content-fix)
Mixed content блокирует скрипты и стили на HTTPS-сайте. Научим находить HTTP-ресурсы, чинить их автоматически через CSP и upgrade-insecure-requests.
Mixed Content: как найти и исправить HTTP-ресурсы на HTTPS-сайте
Mixed content — это ситуация, когда HTTPS-страница подгружает ресурсы (изображения, скрипты, стили, iframes) по HTTP. Современные браузеры либо блокируют такие ресурсы (active mixed content — скрипты, стили), либо показывают предупреждение (passive — картинки, медиа). В статье разберём, как автоматически найти все проблемы, исправить их в коде и отловить новые через Content-Security-Policy.

Active vs Passive mixed content: что бло...

### [SSL Handshake Failed: причины ошибки и пошаговая диагностика](https://enterno.io/articles/ssl-handshake-failed)
SSL handshake failed — подробный разбор причин и диагностики: протоколы, SNI, cipher suites, сертификаты клиента. Примеры openssl и curl для отладки.
SSL Handshake Failed: причины ошибки и пошаговая диагностика
Ошибка «SSL handshake failed» — собирательное название для десятка разных проблем, возникающих во время установки TLS-соединения. Клиент и сервер не смогли договориться о параметрах: версии протокола, cipher suite, сертификате или SNI. В этой статье разберём все типичные причины, покажем команды для диагностики и дадим алгоритм, который за 15 минут приведёт к первопричине.

Что такое TLS handshake и где он может сломаться
TLS handshake...

### [Просроченный SSL-сертификат: как исправить ошибку NET::ERR_CERT_DATE_INVALID](https://enterno.io/articles/ssl-certificate-expired-fix)
Просрочен SSL-сертификат? Узнайте, как быстро диагностировать и исправить ошибку NET::ERR_CERT_DATE_INVALID, продлить сертификат и настроить мониторинг.
Просроченный SSL-сертификат: как исправить ошибку NET::ERR_CERT_DATE_INVALID
Просроченный SSL-сертификат — одна из самых частых и болезненных причин недоступности сайта: браузер показывает красный экран «Ваше подключение не защищено» (NET::ERR_CERT_DATE_INVALID), и пользователи уходят. Обычно это происходит в нерабочее время и обнаруживается только через часы. В этой статье разберём, как за 10 минут диагностировать проблему, выпустить новый сертификат и настроить мониторинг, чтобы это не повтори...

### [Защита от SQL injection: prepared statements и ORM](https://enterno.io/articles/sql-injection-prevention)
SQL injection: типы атак, prepared statements, PDO, параметризация, ORM, least privilege, WAF. Примеры PHP, Node.js, Python.
Защита от SQL injection: prepared statements и ORM
SQL injection — классическая уязвимость из OWASP Top 10: Injection, которая даже в 2026 году регулярно всплывает в production-инцидентах. Одна строка ' OR '1'='1 в поле логина может обойти аутентификацию, украсть всю базу или дать RCE через UDF. В этой статье — типы SQLi, правильная защита через prepared statements, роль ORM, настройка least privilege и fallback-защита через WAF.

Как работает SQL injection
Классическая уязвимость — конкатенация...

### [WAF (Web Application Firewall): базовый гайд](https://enterno.io/articles/web-application-firewall-waf)
Web Application Firewall: что такое WAF, mod_security, cloud WAF (Cloudflare, AWS), OWASP CRS, когда нужен и как не заблокировать легитимный трафик.
WAF (Web Application Firewall): базовый гайд
WAF (Web Application Firewall) — это прокси, который фильтрует HTTP-трафик на прикладном уровне и блокирует атаки по сигнатурам и правилам: SQL injection, XSS, path traversal, RCE-паттерны, credential stuffing, DDoS. В отличие от классического network firewall (L3/L4), WAF работает на L7 — видит полный URL, заголовки, тело запроса. Разбираем варианты (self-hosted mod_security, Cloudflare, AWS WAF), OWASP Core Rule Set и когда WAF реально нужен.

Что д...

### [Subresource Integrity (SRI): защита CDN-скриптов](https://enterno.io/articles/subresource-integrity-sri)
Subresource Integrity (SRI) — атрибут integrity для <script> и <link>. Защита от компрометации CDN, генерация хеша, CSP require-sri-for.
Subresource Integrity (SRI): защита CDN-скриптов
Subresource Integrity (SRI) — атрибут integrity на тегах &lt;script&gt; и &lt;link&gt;, который заставляет браузер сверить SHA-256/384/512-хеш загруженного файла с ожидаемым. Если хеш не совпадает — скрипт не выполнится. SRI защищает от сценария «взломали CDN → залили троян → все клиенты скомпрометированы», реальный инцидент с event-stream и Magecart.

Как работает SRI
Стандарт описан в W3C Subresource Integrity. Пример:
&lt;script
  src="https://...

### [API Rate Limiting: token bucket, 429, Retry-After](https://enterno.io/articles/api-rate-limiting-protection)
Rate limiting API: алгоритмы token bucket и sliding window, заголовок Retry-After, HTTP 429. Реализация на Redis, nginx, Express, NestJS.
API Rate Limiting: token bucket, 429, Retry-After
Rate limiting — это ограничение частоты запросов к API на одного клиента. Цели: предотвратить брутфорс auth-эндпоинтов, защитить от DDoS, сохранить инфраструктуру от злоупотребления тяжёлыми запросами, справедливо распределить ресурсы между тарифами. В статье разберём алгоритмы (token bucket, sliding window), HTTP 429 + Retry-After и реализации на Redis, nginx, Express.

Зачем rate limiting

  Защита от credential stuffing (автоперебор паролей)
 ...

### [Cookie Security: HttpOnly, Secure, SameSite, __Host-](https://enterno.io/articles/cookie-security-httponly-samesite)
Безопасность cookies: HttpOnly, Secure, SameSite (Strict/Lax/None), __Host- префикс, Max-Age vs Expires. Примеры PHP, Express, nginx.
Cookie Security: HttpOnly, Secure, SameSite, __Host-
Cookie — главный механизм состояния сессии в HTTP. Флаги HttpOnly, Secure, SameSite и префиксы __Host-/__Secure- определяют, может ли XSS украсть сессию, работает ли CSRF, передаётся ли cookie по HTTP. В статье — полный разбор атрибутов RFC 6265bis с примерами для PHP, Express и nginx.

HttpOnly
Флаг HttpOnly запрещает JavaScript читать cookie через document.cookie. Обязателен для session-cookie — без него любой XSS краннёт токен. Документация...

### [Миграция с HTTP на HTTPS: редиректы, mixed content, HSTS](https://enterno.io/articles/http-to-https-migration)
Переход с HTTP на HTTPS: получение сертификата, 301 редирект, fix mixed content, HSTS, canonical URL, SEO без потерь трафика.
Миграция с HTTP на HTTPS: редиректы, mixed content, HSTS
HTTPS перестал быть опциональным ещё в 2018, когда Chrome начал помечать HTTP-сайты как «Not Secure», а Google сделал HTTPS фактором ранжирования. Миграция кажется простой (поставил сертификат → редирект), но 30% проектов теряют трафик из-за mixed content, неправильных canonical или забытых поддоменов. Разбираем пошаговый план миграции без потерь SEO и с максимальной безопасностью.

Шаг 1. Сертификат
Бесплатный вариант — Let's Encrypt чере...

### [Защита от XSS атак: типы, эскейпинг, CSP, Trusted Types](https://enterno.io/articles/prevent-xss-attacks)
XSS атаки: stored, reflected, DOM-based. Защита: HTML-эскейпинг, контекстная санитизация, CSP, Trusted Types. Примеры кода и проверка.
Защита от XSS атак: типы, эскейпинг, CSP, Trusted Types
XSS (Cross-Site Scripting) — исполнение злоумышленником произвольного JavaScript в контексте вашего домена. Последствия: кража session cookies, keylogging, фишинг, полный захват аккаунта. XSS входит в OWASP Top 10: Injection и остаётся в топе находок любого pentest. В статье — три типа XSS, правильный эскейпинг по контексту, CSP и Trusted Types как defense-in-depth.

Три типа XSS

  Stored XSS — полезная нагрузка сохраняется в БД (комментар...

### [Защита от Clickjacking: X-Frame-Options vs frame-ancestors](https://enterno.io/articles/clickjacking-prevention)
Clickjacking атаки: как работают, X-Frame-Options, CSP frame-ancestors, SameSite cookies, JS frame-busting. Настройка nginx и проверка защиты.
Защита от Clickjacking: X-Frame-Options vs frame-ancestors
Clickjacking (UI redress attack) — это атака, при которой злоумышленник встраивает ваш сайт в прозрачный iframe на своей странице и заставляет пользователя кликать по «невидимым» кнопкам: подтвердить платёж, сменить пароль, добавить разрешение. Защита от clickjacking — один из самых простых security-фиксов, но его всё ещё нет у 40% российских сайтов (по данным Security Scanner). Разбираем механику атаки и три слоя защиты: X-Frame-Options...

### [CORS: полное руководство по Access-Control-Allow](https://enterno.io/articles/cors-access-control-guide)
CORS, preflight OPTIONS, Access-Control-Allow-Origin, credentials, типичные ошибки. Настройка nginx, Express, NestJS и отладка через curl.
CORS: полное руководство по Access-Control-Allow
CORS (Cross-Origin Resource Sharing) — механизм, которым сервер разрешает браузеру использовать свои ресурсы из другого origin. Без CORS любой JS с чужого домена не может прочитать ответ вашего API — это фундамент Same-Origin Policy. В этой статье разберём preflight-запрос, заголовки Access-Control-Allow-*, работу с credentials и типичные ошибки вида «has been blocked by CORS policy».

Same-Origin Policy и зачем нужен CORS
Origin — это тройка (sch...

### [CSP (Content Security Policy): настройка с нуля](https://enterno.io/articles/csp-content-security-policy-setup)
Настройка Content Security Policy: директивы, nonce, strict-dynamic, report-uri. Готовые примеры для nginx и Next.js, отладка и типичные ошибки.
CSP (Content Security Policy): настройка с нуля
Content Security Policy (CSP) — это заголовок HTTP-ответа, который декларирует браузеру допустимые источники скриптов, стилей, изображений, шрифтов и других ресурсов. Корректно написанный CSP превращает XSS-уязвимость в логирование инцидента, а не в компрометацию сессии. В статье — полный цикл настройки: от Report-Only до строгого strict-dynamic с nonces.

Как работает CSP
Браузер получает заголовок Content-Security-Policy и для каждой загружаемой ...

### [Wildcard DNS-записи: применение и подводные камни](https://enterno.io/articles/wildcard-dns-records)
Wildcard DNS (*.example.com): когда использовать, ограничения по RFC 4592, конфликты, производительность и безопасность.
Wildcard DNS-записи: применение и подводные камни
Wildcard-запись (*.example.com) — удобный способ обрабатывать бесконечное количество поддоменов одним правилом. Но за удобством скрываются подводные камни: wildcard-ы легко дают конфликт с более специфичными записями, мешают CAA и DNSSEC, открывают новые векторы атак. В статье — применение, ограничения по RFC 4592 и рекомендации.

Что такое wildcard
Звёздочка в DNS означает «любая строка вместо меня». Запись:
*.example.com.  3600  IN  A  93.184.2...

### [Обратный DNS и PTR-записи: для чего нужны](https://enterno.io/articles/reverse-dns-ptr-records)
Что такое rDNS и PTR-запись. Настройка обратной зоны in-addr.arpa, PTR для почтовых серверов, влияние на SPF и доставляемость писем.
Обратный DNS и PTR-записи: для чего нужны
Обычный DNS превращает имя в IP. Обратный DNS (rDNS) делает обратное — по IP возвращает доменное имя. Ключевая запись — PTR. Она нужна редко для пользовательских сайтов, но критична для почтовых серверов, систем логирования и диагностики. Разбираемся, как это работает и зачем.

Что такое rDNS и PTR
PTR (Pointer) — запись в специальной зоне in-addr.arpa (для IPv4) или ip6.arpa (для IPv6). Она отображает IP в обратном порядке на доменное имя:
34.216.184.93...

### [DNS leak: что это, как проверить и устранить](https://enterno.io/articles/dns-leak-test-fix)
DNS leak в VPN — что это, чем опасен и как исправить. Пошаговая проверка на Windows, macOS, Linux, iOS и Android.
DNS leak: что это, как проверить и устранить
Вы подключились к VPN и уверены в анонимности. Но DNS-запросы по-прежнему уходят провайдеру — это DNS leak. Несмотря на зашифрованный трафик, провайдер (или случайный наблюдатель) видит, какие домены вы посещаете. В статье — как обнаружить утечку и исправить её на всех популярных платформах.

Что такое DNS leak
При использовании VPN весь трафик должен идти через туннель. Но если ОС или приложение отправляет DNS-запросы в обход туннеля — напрямую на ре...

### [Типы DNS серверов: рекурсивные, авторитативные, root](https://enterno.io/articles/dns-server-types-explained)
Как устроены DNS-серверы: root, TLD, авторитативные, рекурсивные и кэширующие. Полная схема работы DNS с примерами.
Типы DNS серверов: рекурсивные, авторитативные, root
DNS — это иерархическая распределённая система. За каждым успешным dig-запросом стоит работа нескольких типов серверов: корневых (root), TLD, авторитативных и рекурсивных. В статье — как они взаимодействуют, кто за что отвечает, и почему понимание этой схемы критично для диагностики проблем с доменами.

Иерархия DNS
Домены имеют древовидную структуру с пустым корнем (.) наверху:
           .  (root)
           |
       com / org / ru  (TLD)
  ...

### [DNS TTL: best practices и оптимальные значения](https://enterno.io/articles/dns-ttl-best-practices)
DNS TTL best practices: какие значения выставлять для A, MX, NS, TXT. Как TTL влияет на миграции, failover и нагрузку на DNS.
DNS TTL best practices: оптимальные значения
TTL (Time To Live) — одно из важнейших значений в DNS. Оно определяет, сколько секунд резолверы и клиенты хранят запись в кэше. Слишком большой TTL — тяжёлые миграции. Слишком маленький — лишняя нагрузка на авторитативные DNS. В статье — рекомендуемые значения для каждого типа записи и сценарии, когда их стоит корректировать.

Что такое TTL
TTL указывается в секундах и прикреплён к каждой записи в зоне:
example.com.  3600  IN  A  93.184.216.34
Здесь 3...

### [MX-записи для почты: настройка пошагово](https://enterno.io/articles/mx-records-email-setup)
Полная настройка MX-записей для Google Workspace, Yandex 360, Zoho. Приоритет, RFC 5321, SPF/DKIM/DMARC и проверка доставки.
MX-записи для почты: настройка пошагово
MX (Mail Exchanger) — запись DNS, которая говорит отправляющему серверу, куда доставлять письма для вашего домена. Ошибка в MX = вся почта не доходит до адресатов, а вы узнаёте об этом из NDR-отбивок клиентов. В статье — пошаговая настройка MX для Google Workspace, Yandex 360, Zoho, своего сервера, а также SPF/DKIM/DMARC, без которых ваши письма пойдут в спам.

Что такое MX-запись
MX хранит имя сервера, принимающего почту, и приоритет:
example.com.  3600  ...

### [CNAME vs A-запись: разница и когда что использовать](https://enterno.io/articles/cname-vs-a-record)
CNAME или A-запись? Разбираем различия, производительность, ограничения RFC 1034/1912 и сценарии использования для apex-домена, CDN, подмена.
CNAME vs A-запись: разница и когда что использовать
А-запись и CNAME — два самых частых типа DNS-записей. Их нередко путают, и эта путаница приводит к проблемам: apex-домен отказывается резолвиться, CDN работает не для всех, SSL ломается. В статье — подробное сравнение, ограничения по RFC и конкретные сценарии использования.

Что такое A-запись
A (Address) — запись, связывающая доменное имя с IPv4-адресом. Пример:
example.com.      3600  IN  A  93.184.216.34
Для IPv6 используется тип AAAA. A-зап...

### [Как очистить DNS кэш: Windows, Mac, Linux, браузеры](https://enterno.io/articles/dns-cache-flush-guide)
Полный гайд по очистке DNS-кэша: команды для Windows, macOS, Linux, Chrome, Firefox, Safari. Когда это нужно и почему не работает.
Как очистить DNS кэш: Windows, Mac, Linux, браузеры
DNS-кэш ускоряет работу интернета: ОС и браузер запоминают ответ резолвера и не запрашивают его при каждом посещении. Но при смене IP сайта, миграции NS или проблемах с доступностью старый кэш превращается в помеху — пользователь ходит на устаревший IP. В этой статье — пошаговые команды для всех платформ и браузеров.

Когда нужно сбрасывать DNS-кэш

  Изменился IP сайта, а он по-прежнему открывается по-старому.
  Переехали хостинг или NS, TTL е...

### [Как проверить распространение DNS: 5 инструментов](https://enterno.io/articles/check-dns-propagation-tools)
Проверка DNS propagation в 2026: 5 лучших инструментов, принцип работы, разбор команд dig/nslookup, как ускорить распространение.
Как проверить распространение DNS: 5 инструментов
После смены IP, NS или любых записей DNS изменения не мгновенны. До тех пор, пока все рекурсивные резолверы в мире не обновят свой кэш, часть пользователей будет получать старый ответ. Этот процесс называют «DNS propagation», и проверять его нужно не только при миграциях, но и при диагностике проблем с доступностью.
В статье разберём, как именно происходит распространение, и дадим 5 проверенных инструментов — от простых веб-сервисов до команд в т...

### [Сайт не открывается из-за DNS: 8 причин и решения](https://enterno.io/articles/dns-not-resolving-fix)
Сайт не открывается, а DNS не резолвится? Разбираем 8 частых причин — от TTL и кэша до NS и firewall. Пошаговая диагностика и инструменты.
Сайт не открывается из-за DNS: 8 причин и решения
Когда браузер показывает ошибку DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL или просто «Не удаётся получить доступ к сайту», проблема почти всегда лежит на уровне DNS. Сайт может быть полностью рабочим на хостинге, но пользователь до него не доходит: резолвер не смог превратить имя домена в IP-адрес. Такие ошибки критичны для бизнеса — они выглядят как полный простой, хотя серверы в порядке.
В этой статье — 8 самых распространённых причин, по которым D...

### [Cache-Control заголовки: полный гид по кэшированию](https://enterno.io/articles/http-cache-control-headers)
Cache-Control полное руководство — max-age, no-store, stale-while-revalidate, public/private, настройка в nginx/Apache для статики, HTML, API.
Заголовок Cache-Control — главный инструмент управления кэшированием в HTTP. Правильная настройка сокращает загрузку сервера, ускоряет сайт для пользователей и улучшает Core Web Vitals. Неправильная — приводит к «залипшему» контенту, пропаже обновлений и SEO-проблемам.В этом гайде разберём все директивы Cache-Control, отношения с ETag, Last-Modified и Vary, стратегии для разных типов контента (статика, HTML, API), примеры настройки в nginx и Apache.Что такое Cache-ControlПо RFC 9111, Cache-Contr...

### [Цепочки редиректов и их влияние на SEO](https://enterno.io/articles/http-redirect-chains-seo)
Цепочки редиректов снижают SEO-вес, замедляют загрузку и расходуют crawl budget. Как найти и устранить 301/302 chain через инструменты и код.
Цепочки редиректов (redirect chains) — ситуация, когда запрос проходит через несколько промежуточных 301/302 прежде чем достичь финального URL. Пример: http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. Это 4 запроса вместо одного, и это медленно, неэффективно и плохо для SEO.Почему цепочки — проблемаSEO-вес теряется. Google официально передаёт PageRank через 301, но каждый хоп теряет 10-15% веса на практике.Crawl budget расходуется...

### [504 Gateway Timeout: причины и решения для админов](https://enterno.io/articles/http-504-gateway-timeout)
Ошибка 504 Gateway Timeout — 6 причин, отличие от 502, правильная настройка timeout в nginx/Apache/PHP-FPM/Node.js с примерами конфигов.
Ошибка 504 Gateway Timeout возникает, когда прокси (nginx, Cloudflare) ждал ответ от upstream дольше, чем разрешено timeout'ом. В отличие от 502 (невалидный ответ), 504 — это ожидание, которое истекло. Разберём причины, как настроить timeout'ы правильно и как оптимизировать медленные запросы, вместо того чтобы просто их скрывать.Что означает 504Согласно RFC 9110 §15.6.5, 504 означает, что сервер, действуя как gateway, не получил своевременный ответ от upstream. Ключевое слово — «своевременный»: ...

### [502 Bad Gateway: что значит и как починить](https://enterno.io/articles/http-502-bad-gateway-fix)
502 Bad Gateway — расшифровка для nginx/Apache + PHP-FPM/Node.js, отличия от 500/504, 7 причин, пошаговые решения с примерами конфигов.
Ошибка 502 Bad Gateway означает, что прокси-сервер (nginx, Apache, Cloudflare) не получил валидный ответ от upstream-сервера (PHP-FPM, Node.js, uwsgi, Gunicorn). Это не проблема прикладного кода, а сбой между прокси и backend'ом.В статье разберём, что конкретно означает 502 в разных stack'ах, 7 частых причин и пошаговые решения для nginx + PHP-FPM, Node.js и Apache, с примерами конфигов.Что означает 502По RFC 9110 §15.6.3, 502 указывает, что сервер, действуя как gateway или proxy, получил некорр...

### [429 Too Many Requests: rate limiting и обход](https://enterno.io/articles/http-429-too-many-requests)
HTTP 429 — как работает rate limiting, настройка nginx limit_req, Redis sliding window, правильная обработка Retry-After на клиенте и API.
Код 429 Too Many Requests — сигнал от сервера: «ты слишком быстро, сбавь темп». Это стандартный ответ rate limiter'а, защищающего API и сайты от злоупотреблений. Разберём, как правильно внедрить 429 на сервере, как клиенту корректно обработать Retry-After, и что делать, если ваш сервис получает 429 от внешнего API.Что означает 429Согласно RFC 6585 §4, 429 указывает, что пользователь отправил слишком много запросов за единицу времени. Это отличие от 503 (сервис недоступен) и 403 (запрещено полити...

### [Ошибка 403 Forbidden: 8 способов исправить](https://enterno.io/articles/http-403-forbidden-fix)
403 Forbidden — причины и решения: права файлов, .htaccess, nginx, WordPress, ModSecurity, IP-блокировки. Пошаговая диагностика через логи.
Ошибка 403 Forbidden означает, что сервер понял запрос, но отказывается его выполнять. В отличие от 401 (нет авторизации), 403 говорит: «я знаю кто ты, но доступа нет». Это серверная политика доступа — на файлы, директории, или конкретные URL.Рассмотрим 8 реальных причин 403 и практические решения для nginx, Apache, WordPress, а также как выявить блокировку через ModSecurity, Cloudflare WAF или rate limiting.Что означает 403По RFC 9110 §15.5.4, 403 означает, что сервер понимает запрос, но не авт...

### [Ошибка 503 Service Unavailable: причины и решения](https://enterno.io/articles/http-503-service-unavailable)
503 Service Unavailable — что означает, как отличить от 500/502, 6 причин и решений для nginx, Apache, PHP-FPM, Kubernetes с примерами конфигов.
Ошибка 503 Service Unavailable — это сервер, который говорит «я жив, но сейчас не могу обслужить запрос». В отличие от 500, это НЕ exception: причина известна серверу и обычно временная. Разберём, какие реальные сценарии вызывают 503, как её правильно использовать как инструмент maintenance, и как быстро восстановить сервис.Что означает 503По RFC 9110 §15.6.4, код 503 означает, что сервер временно не в состоянии обработать запрос из-за перегрузки или планового обслуживания. Это временное состоян...

### [301 vs 302 редирект: разница и когда что использовать](https://enterno.io/articles/http-301-vs-302-redirect)
301 vs 302 редирект — ключевые отличия, влияние на SEO, когда использовать каждый, настройка в nginx, Apache, WordPress, PHP с примерами кода.
301 и 302 — два самых распространённых HTTP-редиректа, и их путают даже опытные разработчики. Неправильный выбор стоит SEO-позиций, ломает аналитику и создаёт циклы редиректов. В этой статье разберём принципиальную разницу, влияние на SEO, когда применять каждый, и покажем примеры настройки в nginx, Apache, PHP и WordPress.Что такое 301 Moved PermanentlyПо RFC 9110 §15.4.2, код 301 говорит: «ресурс переехал навсегда, используйте новый URL во всех будущих запросах». Поисковые системы передают ~90...

### [Ошибка 500 Internal Server Error: что значит и как починить](https://enterno.io/articles/http-500-internal-server-error)
500 Internal Server Error — расшифровка, 8 частых причин, чтение логов PHP и nginx, исправление для WordPress, Laravel и Node.js с примерами.
Ошибка 500 Internal Server Error — серверная (класс 5xx), которая говорит «что-то сломалось, но я не могу объяснить что». Это generic-код: сервер знает о проблеме, но не раскрывает детали клиенту из соображений безопасности. Для администратора 500 — красный флаг, требующий немедленного расследования через логи.Разберём, что именно означает 500, какие 8 типовых причин её вызывают, как быстро найти первопричину в логах PHP, nginx, Apache и Node.js, и как починить для WordPress, Laravel, Symfony и ...

### [Ошибка 404 Not Found: 7 причин и как исправить](https://enterno.io/articles/http-404-not-found-fix)
Ошибка 404 Not Found — 7 реальных причин появления, диагностика через DevTools и логи сервера, пошаговое исправление для пользователей и админов.
Ошибка 404 Not Found — один из самых частых HTTP-кодов, с которым сталкиваются владельцы сайтов и пользователи. Она означает, что сервер получил запрос, но запрошенный ресурс не найден. Несмотря на кажущуюся простоту, за 404 может стоять множество причин: от банальной опечатки в URL до сложных проблем с конфигурацией веб-сервера.В этом гайде разберём, что именно означает 404, какие 7 частых причин её вызывают, как диагностировать проблему через DevTools и логи, и какие решения работают в 2026 го...

### [DNS-записи: полный гид для веб-мастера](https://enterno.io/articles/dns-records-guide)
Типы DNS записей: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA — полный гид для веб-мастера с примерами и типичными ошибками.
Что такое DNS и зачем веб-мастеру знать типы записей

DNS (Domain Name System) — это распределённая база данных, которая связывает человекочитаемые доменные имена с IP-адресами и другими техническими данными. Когда пользователь вводит example.com в браузере, DNS-резолвер последовательно обходит серверы имён, чтобы найти IP-адрес сервера, к которому нужно подключиться. Весь этот процесс занимает миллисекунды, но от его корректной настройки зависит доступность сайта, работа почты и уровень защиты ...

### [Как проверить SSL-сертификат и не пропустить истечение](https://enterno.io/articles/ssl-certificate-check)
Как проверить SSL-сертификат сайта: через браузер, OpenSSL и онлайн-инструменты. Типы сертификатов, цепочка доверия и мониторинг.
Браузер показывает замок в адресной строке — и большинство владельцев сайтов считают, что с SSL всё в порядке. Пока в один день не приходит уведомление хостинга, что сертификат истёк три дня назад, а посетители видят предупреждение «Ваше соединение не защищено». Трафик падает, доверие теряется, поисковики фиксируют сигнал о неблагонадёжности.Что такое SSL/TLS-сертификатSSL-сертификат (технически TLS, но термин «SSL» прижился) — это цифровой документ, подтверждающий: сервер принадлежит тому, кем ...

### [ТОП-10 сервисов мониторинга сайтов 2026: честное сравнение функций и цен](https://enterno.io/articles/monitoring-services-comparison-2026)
Сравнение лучших сервисов мониторинга доступности сайтов в 2026 году: UptimeRobot, Ping-Admin, Better Uptime, Enterno.io и другие. Функции, цены, плюсы и минусы.
Выбор сервиса мониторинга — стратегическое решение. От него зависит, как быстро вы узнаете о проблемах с сайтом, какие данные получите для анализа и сколько будете платить. Мы сравнили 10 популярных платформ по ключевым критериям: частота проверок, каналы уведомлений, количество мониторов, наличие статус-страниц и цена.

Критерии сравнения

При выборе сервиса мониторинга обращайте внимание на:


Минимальный интервал проверки — как часто сервис проверяет ваш сайт. 30 секунд = обнаружение за полми...

### [Как проверить сайт на вирусы и вредоносный код: 7 методов](https://enterno.io/articles/website-malware-check)
7 способов проверить сайт на вирусы, вредоносный код и фишинг. Онлайн-сканеры, ручные методы, мониторинг и профилактика заражения.
Взломанный сайт — это потеря трафика, репутации и данных пользователей. Поисковые системы блокируют заражённые ресурсы, браузеры показывают предупреждения, а хостинг-провайдеры отключают аккаунт. Чем раньше обнаружена угроза, тем меньше ущерб.

В этой статье — 7 практических методов проверки сайта на вирусы: от быстрых онлайн-сканеров до глубокого серверного анализа.

1. Онлайн-сканеры безопасности

Самый быстрый способ — проверить URL через внешние сканеры. Они анализируют HTML-код страницы, Ja...

### [SPF, DKIM и DMARC: что это, зачем нужны и как настроить для защиты почты](https://enterno.io/articles/spf-dkim-dmarc-guide)
Полное руководство по настройке SPF, DKIM и DMARC. Узнайте, как защитить почтовый домен от подделки, улучшить доставляемость и пройти проверку у Gmail и Яндекса.
Ежедневно отправляются миллиарды поддельных писем — фишинг, спуфинг, мошенничество от имени чужих доменов. Три протокола — SPF, DKIM и DMARC — составляют современный стандарт аутентификации электронной почты. С 2024 года Google и Yahoo требуют их наличие у всех массовых отправителей. Без них письма попадают в спам или вовсе отклоняются.

В этом руководстве разберём каждый протокол: что он делает, как работает и как правильно настроить. В конце — чеклист проверки и частые ошибки.

Что такое SPF и...

### [Graceful Degradation и Progressive Enhancement: стратегии и практические примеры](https://enterno.io/articles/graceful-degradation-vs-progressive-enhancement)
Сравнение подходов graceful degradation и progressive enhancement в веб-разработке. Практические стратегии, примеры кода и рекомендации по выбору подхода для отказоустойчивых веб-приложений.
Две философии отказоустойчивой веб-разработки
Graceful degradation (плавная деградация) и progressive enhancement (прогрессивное улучшение) — два взаимодополняющих подхода к созданию веб-приложений, работающих на разнообразных браузерах, устройствах и в различных сетевых условиях. Разделяя цель широкой доступности, они принципиально различаются в отправной точке и мышлении.
Graceful degradation начинает с полного функционала и обеспечивает приемлемую работу при отсутствии возможностей. Progressi...

### [Certificate Transparency Logs: обнаружение поддельных сертификатов и мониторинг домена](https://enterno.io/articles/certificate-transparency-logs)
Узнайте, как работают логи прозрачности сертификатов, почему они важны для безопасности, и как мониторить CT-логи для обнаружения несанкционированных сертификатов вашего домена.
Что такое логи прозрачности сертификатов?
Certificate Transparency (CT) — это открытый фреймворк для мониторинга и аудита SSL/TLS-сертификатов. Созданный Google в 2013 году и стандартизированный как RFC 6962, CT требует от удостоверяющих центров (CA) публично логировать каждый выпущенный сертификат. Эти журналы, доступные только для добавления записей и криптографически верифицируемые, позволяют владельцам доменов, браузерам и исследователям безопасности обнаруживать ошибочно выпущенные или моше...

### [Бюджеты производительности: установка, контроль и автоматизация лимитов](https://enterno.io/articles/web-performance-budget)
Узнайте, как создавать и контролировать бюджеты веб-производительности с использованием метрик LCP, размера бандла и количества запросов. Интеграция бюджетов в CI/CD для автоматического контроля.
Что такое бюджет производительности?
Бюджет производительности — это набор количественных лимитов на метрики, влияющие на пользовательский опыт. Эти лимиты выступают защитными барьерами, предотвращая попадание регрессий производительности в продакшен. В отличие от абстрактных целей, бюджеты обеспечиваются принудительно — сборки, превышающие их, падают, пулл-реквесты получают предупреждения, и команды оповещаются до того, как деградация попадет в релиз.
Бюджеты производительности превращают работ...

### [Мульти-CDN стратегия: отказоустойчивость, оптимизация затрат и распределение трафика](https://enterno.io/articles/multi-cdn-strategy)
Подробное руководство по внедрению мульти-CDN архитектуры для повышения надежности, снижения задержек, оптимизации затрат и интеллектуального распределения трафика между провайдерами.
Зачем использовать несколько CDN?
Зависимость от одного CDN-провайдера создает единую точку отказа, которая может повлиять на всю глобальную аудиторию. Мульти-CDN стратегии распределяют трафик между двумя или более CDN-провайдерами, обеспечивая значительные преимущества в надежности, производительности и управлении затратами.
Крупные сбои у ведущих CDN-провайдеров продемонстрировали, что даже самые надежные сети подвержены простоям. Мульти-CDN подход гарантирует доступность вашего контента даже ...

### [Real User Monitoring: полное руководство по RUM и синтетическому мониторингу](https://enterno.io/articles/real-user-monitoring-guide)
Узнайте разницу между Real User Monitoring и синтетическим мониторингом, как отслеживать Core Web Vitals и какие инструменты RUM использовать для анализа производительности.
Что такое Real User Monitoring?
Real User Monitoring (RUM) — это подход к мониторингу производительности, который фиксирует и анализирует каждую транзакцию реальных пользователей на сайте или в приложении. В отличие от синтетического мониторинга, имитирующего действия пользователей из контролируемых сред, RUM собирает данные из реальных браузерных сессий, обеспечивая подлинное представление о пользовательском опыте на разных устройствах, сетях и в разных регионах.
RUM работает путем внедрения не...

### [HSTS и список предзагрузки: полное руководство по внедрению](https://enterno.io/articles/http-strict-transport-security-preload)
Полное руководство по заголовку HTTP Strict Transport Security (HSTS) и списку предзагрузки. Этапы внедрения, риски, стратегия отката и лучшие практики.
HTTP Strict Transport Security (HSTS) и предзагрузка
HTTP Strict Transport Security — это механизм безопасности, который заставляет браузеры взаимодействовать с вашим сайтом исключительно по HTTPS. После получения заголовка HSTS браузер откажется подключаться по обычному HTTP на указанный срок, устраняя целый класс атак. Список предзагрузки HSTS идет дальше, встраивая ваш домен в код браузеров, обеспечивая принудительный HTTPS с самого первого посещения.

Почему HSTS важен
Даже если ваш сервер п...

### [Anycast DNS: как работает, преимущества и реализация](https://enterno.io/articles/anycast-dns-explained)
Узнайте, как работает anycast-маршрутизация для DNS. Преимущества для отказоустойчивости, скорости и защиты от DDoS. Практическое руководство по внедрению.
Anycast DNS: полное объяснение
Anycast — это методология сетевой адресации и маршрутизации, при которой один и тот же IP-адрес объявляется из множества точек по всему миру. При использовании для DNS anycast-маршрутизация обеспечивает ответ от географически ближайшего сервера, радикально снижая задержку и повышая отказоустойчивость. В этой статье объясняется, как работает anycast DNS, почему это важно и как его внедрить.

Понимание методов маршрутизации
Прежде чем углубляться в anycast, полезно п...

### [Resource Hints: Prefetch, Preload, Preconnect и DNS-Prefetch](https://enterno.io/articles/prefetch-preload-preconnect)
Полное руководство по ресурсным подсказкам браузера: prefetch, preload, preconnect и dns-prefetch. Узнайте, когда использовать каждую для оптимальной производительности.
Ресурсные подсказки: Prefetch, Preload, Preconnect, DNS-Prefetch
Ресурсные подсказки (resource hints) — это HTML-директивы, которые помогают браузеру оптимизировать загрузку ресурсов. Сообщая браузеру о необходимых ресурсах заранее, вы можете устранить сетевые задержки, сократить время блокировки рендеринга и значительно улучшить производительность загрузки страницы. Понимание различий между каждой подсказкой необходимо для их правильного применения.

Обзор ресурсных подсказок


ПодсказкаНазначе...

### [Чек-лист безопасности веб-сервера: Nginx и Apache](https://enterno.io/articles/web-server-hardening)
Полный чек-лист по усилению безопасности веб-серверов nginx и Apache. Права доступа, заголовки безопасности, настройка TLS, контроль доступа и мониторинг.
Чек-лист безопасности веб-сервера
Защита веб-сервера — одна из самых критичных задач при работе в продакшене. Неправильно настроенный сервер открывает приложение для утечек данных, дефейса, внедрения вредоносного кода и атак типа «отказ в обслуживании». Этот чек-лист охватывает основные шаги по усилению безопасности серверов nginx и Apache.

Почему усиление безопасности важно
Конфигурации серверов по умолчанию отдают приоритет удобству настройки, а не безопасности. Стандартные установки часто ра...

### [Как выбрать идеальное доменное имя: полное руководство](https://enterno.io/articles/domain-name-choosing-guide)
Узнайте, как правильно выбрать доменное имя для вашего проекта. Выбор TLD, советы по брендингу, типичные ошибки и практические рекомендации.
Как выбрать идеальное доменное имя
Доменное имя — это фундамент вашего присутствия в интернете. Оно влияет на брендинг, SEO, доверие пользователей и долгосрочный успех бизнеса. Неправильный выбор домена может стоить вам трафика, репутации и денег. Это руководство проведет вас через все этапы выбора идеального домена для вашего проекта.

Почему доменное имя так важно
Доменное имя — это больше, чем просто веб-адрес. Это первое впечатление о вашем бренде в интернете. Исследования показывают, что 77...

### [Стратегии версионирования API: URL, заголовки и параметры запроса](https://enterno.io/articles/api-versioning-strategies)
Сравнение методов версионирования API: URL-путь, пользовательские заголовки и параметры запроса. Лучшие практики обратной совместимости и процесс депрекации.
Почему версионирование API важно
API — это контракт между поставщиком сервиса и потребителями. По мере развития API ломающие изменения неизбежны: новые поля, переименованные эндпоинты, измененные структуры ответов, устаревшая функциональность. Без стратегии версионирования каждое изменение рискует сломать существующие интеграции. Грамотный подход к версионированию обеспечивает эволюцию при сохранении стабильности.

Три основных подхода к версионированию

1. Версионирование через URL-путь
Наиболе...

### [TTL в DNS: оптимальные значения для каждого типа записи](https://enterno.io/articles/dns-record-ttl-guide)
Как значения TTL в DNS влияют на скорость распространения, кеширование и стратегии миграции. Практические рекомендации для записей A, CNAME, MX, TXT и NS.
Что такое DNS TTL?
TTL (Time to Live) — значение в DNS-записи, указывающее резолверам, как долго кешировать ответ перед повторным запросом к авторитативному серверу имен. Измеряется в секундах и напрямую влияет на скорость распространения изменений DNS, нагрузку на серверы имен и устойчивость инфраструктуры к сбоям DNS.

Как работает DNS-кеширование
Когда пользователь посещает ваш сайт, его устройство отправляет запрос рекурсивному резолверу (обычно предоставляемому провайдером или публичным сер...

### [Управление логами: лучшие практики для продакшена](https://enterno.io/articles/log-management-best-practices)
Централизованное логирование, структурированные логи, политики хранения и настройка алертов. Полное руководство по управлению логами для DevOps-команд.
Почему управление логами важно
Логи — единственный достоверный источник информации при диагностике инцидентов в продакшене. Тем не менее многие команды относятся к логированию как к второстепенной задаче, получая неструктурированные, разрозненные и перегруженные данные, которые невозможно эффективно запросить в критический момент. Правильное управление логами превращает сырой вывод в действенную аналитику.

Архитектура централизованного логирования
Первый шаг к эффективному управлению логами — ц...

### [TLS-рукопожатие: пошаговое руководство по установке защищенного соединения](https://enterno.io/articles/ssl-handshake-explained)
Разбор процесса TLS-рукопожатия по шагам. Сравнение TLS 1.2 и 1.3, влияние на производительность и рекомендации по настройке SSL/TLS.
Что такое TLS-рукопожатие?
TLS-рукопожатие (TLS handshake) — это процесс, в ходе которого клиент и сервер устанавливают зашифрованное соединение. Каждый раз при посещении HTTPS-сайта происходит TLS-рукопожатие до передачи любых данных приложения. Понимание этого процесса необходимо для диагностики проблем соединения, оптимизации производительности и настройки безопасных серверов.

TLS 1.2: пошаговый разбор
Рукопожатие TLS 1.2 требует двух циклов обмена данными между клиентом и сервером до начала...

### [Поддомен или подкаталог для SEO: какая структура лучше?](https://enterno.io/articles/subdomain-vs-subdirectory-seo)
Сравнение поддоменов и подкаталогов для SEO. Плюсы, минусы и рекомендации по выбору URL-структуры для максимальной видимости в поисковых системах.
Поддомен или подкаталог: вечный спор в SEO
Один из самых обсуждаемых вопросов технического SEO — размещать контент на поддомене (blog.example.com) или в подкаталоге (example.com/blog). Выбор влияет на то, как поисковые системы сканируют, индексируют и распределяют авторитетность между вашими страницами. Хотя Google заявляет, что оба подхода обрабатываются одинаково, практика показывает более сложную картину.

Структурные различия
Поддомен — это отдельная секция сайта, существующая как префикс ос...

### [Мониторинг как код: правила Prometheus и дашборды Grafana](https://enterno.io/articles/monitoring-as-code)
Узнайте, как реализовать мониторинг как код с правилами алертинга Prometheus, записывающими правилами и дашбордами Grafana в версионируемых конфигурационных файлах.
Мониторинг как код: полное руководство
Мониторинг как код (Monitoring as Code, MaC) применяет принципы инфраструктуры как кода к наблюдаемости. Вместо ручной настройки дашбордов, алертов и записывающих правил через веб-интерфейсы, вся конфигурация мониторинга определяется в версионируемых файлах, проверяется через пулл-реквесты и развёртывается через CI/CD-пайплайны.

Зачем мониторинг как код?
Ручная настройка мониторинга создаёт хрупкие, недокументированные системы наблюдаемости, которые сложно...

### [Настройка TCP-соединений: Keepalive, размер окна и алгоритм Нейгла](https://enterno.io/articles/tcp-connection-tuning)
Освойте параметры настройки TCP-соединений: keepalive, оптимизация размера окна и алгоритм Нейгла для улучшения сетевой производительности.
Настройка TCP-соединений: практическое руководство
TCP (Transmission Control Protocol) обеспечивает надёжную упорядоченную доставку данных по сети, но его настройки по умолчанию часто неоптимальны для современных приложений. Понимание и настройка параметров TCP может значительно улучшить пропускную способность, снизить задержки и оптимизировать использование ресурсов для ваших конкретных нагрузок.

Настройка TCP Keepalive
TCP keepalive — механизм обнаружения мёртвых соединений путём периодическо...

### [Руководство по XML Sitemap: создание, структура и лучшие практики](https://enterno.io/articles/sitemap-xml-guide)
Узнайте, как создавать и оптимизировать XML-карты сайта для поисковых систем: структура, способы отправки и типичные ошибки.
XML Sitemap: всё, что нужно знать
XML-карта сайта (sitemap) — это структурированный файл, помогающий поисковым системам обнаруживать, сканировать и индексировать страницы вашего сайта эффективно. Хотя поисковые системы могут находить страницы через ссылки, карта сайта предоставляет прямой маршрут ко всему важному контенту, гарантируя, что ничего не будет пропущено при сканировании.

Структура и формат карты сайта
XML-карты сайта следуют стандартизированному формату, определённому протоколом site...

### [Руководство по двухфакторной аутентификации: TOTP, SMS и аппаратные ключи](https://enterno.io/articles/two-factor-authentication-guide)
Полное руководство по типам двухфакторной аутентификации: TOTP, SMS-верификация и аппаратные ключи безопасности с лучшими практиками внедрения.
Двухфакторная аутентификация: полное руководство
Двухфакторная аутентификация (2FA) добавляет критически важный уровень безопасности помимо паролей. Требуя от пользователей подтверждения личности через два различных фактора — то, что они знают, и то, что у них есть — 2FA значительно снижает риск несанкционированного доступа даже при компрометации паролей.

Типы факторов аутентификации
Факторы аутентификации подразделяются на три основные группы. Надёжная реализация 2FA комбинирует факторы из как...

### [Оптимизация доставки контента: стратегии CDN и граничные вычисления](https://enterno.io/articles/content-delivery-optimization)
Изучите продвинутые стратегии оптимизации CDN, паттерны граничных вычислений и проектирование иерархии кэширования для быстрой доставки контента пользователям по всему миру.
Оптимизация доставки контента: полное руководство
Оптимизация доставки контента — одна из самых значимых областей веб-инженерии производительности. Стратегическое размещение контента ближе к пользователям и внедрение интеллектуальных иерархий кэширования позволяет организациям значительно снизить задержки и улучшить пользовательский опыт для глобальной аудитории.

Архитектура CDN
Сеть доставки контента (CDN) работает через распределённую сеть граничных серверов, также известных как точки присутс...

### [Проектирование health check эндпоинтов для веб-сервисов](https://enterno.io/articles/health-check-endpoints)
Узнайте, как строить health check эндпоинты: liveness vs readiness, проверка зависимостей, формат ответов.
Health check эндпоинт — выделенный URL, сообщающий о состоянии приложения. Основа автоматического мониторинга, маршрутизации балансировщика и оркестрации контейнеров. Правильный health check предотвращает ложные срабатывания и даёт actionable информацию.

Типы health check

Liveness Check
Отвечает: «Процесс приложения работает?» Минимальная проверка — при неудаче приложение нужно перезапустить.
GET /health/live → 200 OK
{"status": "alive"}
Проверяйте только сам процесс. Не проверяйте зависимости...

### [Стратегии ограничения частоты запросов для веб-API](https://enterno.io/articles/rate-limiting-strategies)
Изучите алгоритмы rate limiting: token bucket, sliding window, fixed window — и как реализовать эффективное ограничение запросов к API.
Rate limiting контролирует, сколько запросов клиент может сделать к API за определённый период. Защищает инфраструктуру от злоупотреблений, обеспечивает справедливое использование и предотвращает монополизацию ресурсов.

Зачем нужен rate limiting

Защита от DDoS: ограничивает влияние объёмных атак
Справедливость: один пользователь не истощает ресурсы для других
Контроль затрат: ограничение дорогих операций (БД, сторонние API)
Монетизация API: тарифные лимиты (free, pro, business)
Стабильность: з...

### [Веб-доступность: практическое руководство по WCAG для разработчиков](https://enterno.io/articles/website-accessibility-guide)
Основы веб-доступности для разработчиков: руководства WCAG, семантический HTML, ARIA, клавиатурная навигация и инструменты тестирования.
Веб-доступность обеспечивает работу сайтов для всех, включая людей с ограниченными возможностями. Помимо социальной ответственности, доступность всё чаще становится юридическим требованием и напрямую влияет на SEO.

Почему доступность важна

Законодательство: ADA, EU Accessibility Act и подобные законы требуют доступных сайтов
Аудитория: ~15% мирового населения имеют ту или иную форму инвалидности
SEO: доступный HTML = семантический HTML, который поисковики понимают лучше
UX для всех: субтитры п...

### [Заголовок X-Forwarded-For: определение IP клиента за прокси](https://enterno.io/articles/x-forwarded-for-header)
Разбираем заголовок X-Forwarded-For: как работает, почему важен для логирования и безопасности, настройка цепочки доверия.
Когда запрос проходит через прокси, балансировщики или CDN, реальный IP клиента теряется — сервер видит IP прокси. Заголовок X-Forwarded-For (XFF) решает проблему, передавая реальный IP через цепочку прокси.

Как работает X-Forwarded-For
Каждый прокси добавляет IP предыдущего хопа:
Клиент (203.0.113.50) → Прокси1 (10.0.0.1) → Прокси2 (10.0.0.2) → Сервер

X-Forwarded-For: 203.0.113.50, 10.0.0.1
Левый IP — оригинальный клиент. Каждый последующий — прокси в цепочке.

Связанные заголовки

X-Forwarde...

### [Инвалидация кеша CDN: стратегии доставки свежего контента](https://enterno.io/articles/cdn-cache-invalidation)
Освойте техники инвалидации кеша CDN: стратегии очистки, cache-busting, настройка TTL и баланс между свежестью и производительностью.
CDN драматически улучшают производительность, кешируя контент на edge-серверах по всему миру. Но кеширование создаёт фундаментальную проблему: как обеспечить, чтобы пользователи видели обновлённый контент? Инвалидация кеша — процесс удаления или замены устаревшего кешированного контента — одна из сложнейших задач.

Почему инвалидация сложна

Распределённое состояние: контент кеширован на сотнях edge-нод
Задержка распространения: инвалидация занимает от секунд до минут
Консистентность vs скорость...

### [Wildcard SSL-сертификаты: когда и как использовать](https://enterno.io/articles/wildcard-ssl-certificates)
Разбираем wildcard SSL-сертификаты: как работают, последствия для безопасности, когда использовать и лучшие практики настройки.
Wildcard SSL-сертификат защищает домен и все его поддомены одного уровня одним сертификатом. Вместо покупки отдельных сертификатов для www.example.com, api.example.com и app.example.com, wildcard *.example.com покрывает все.

Как работает wildcard
Wildcard использует звёздочку (*) в левой позиции: *.example.com. Покрывает:

www.example.com ✓
api.example.com ✓
app.example.com ✓
anything.example.com ✓


НЕ покрывает:

example.com ✗ (базовый домен — хотя большинство CA включают как SAN)
sub.api.exa...

### [Полный жизненный цикл HTTP-запроса: от URL до отрендеренной страницы](https://enterno.io/articles/http-request-lifecycle)
Проследите каждый шаг HTTP-запроса: DNS, TCP, TLS, HTTP, рендеринг — поймите полный путь от ввода URL до отображения страницы.
Когда вы вводите URL и нажимаете Enter, за миллисекунды разворачивается сложная цепочка событий. Понимание этого цикла фундаментально для веб-разработчиков — это основа диагностики проблем производительности, безопасности и сетевых ошибок.

Шаг 1: Парсинг URL
Браузер разбирает URL на компоненты:
https://www.example.com:443/path/page?query=value#section
│       │                │   │         │           │
схема   хост             порт путь     параметры   фрагмент
Браузер проверяет: это URL или п...

### [IPv4 vs IPv6: различия, миграция и что это значит для вашего сайта](https://enterno.io/articles/ipv4-vs-ipv6)
Разбираем разницу между IPv4 и IPv6, почему переход важен, настройку dual-stack и подготовку инфраструктуры.
Адреса IPv4 заканчиваются. При всего 4,3 миллиарда возможных адресов (многие уже исчерпаны) переход на IPv6 — с 340 ундециллионами адресов — вопрос не «если», а «когда». Понимание обоих протоколов необходимо для современной веб-инфраструктуры.

IPv4
IPv4 — основа интернета с 1981 года. Адреса — 32-битные числа: 192.168.1.100.

Ограничения IPv4

Исчерпание адресов: ~4,3 млрд. IANA распределила последние блоки в 2011.
Зависимость от NAT: Network Address Translation скрывает устройства за одним IP,...

### [MTTR, MTTF, MTBF: метрики надёжности для веб-сервисов](https://enterno.io/articles/mttr-mttf-mtbf-explained)
Разбираем ключевые метрики надёжности — MTTR, MTTF, MTBF — и как использовать их для измерения и улучшения доступности.
Метрики надёжности — язык аптайма. Когда спрашивают «насколько надёжен ваш сервис?», метрики MTTR, MTTF и MTBF дают объективные ответы. Понимание этих метрик помогает устанавливать осмысленные SLA, приоритизировать улучшения и общаться с заинтересованными сторонами.

MTTR — среднее время восстановления
MTTR измеряет среднее время от обнаружения сбоя до восстановления сервиса. Самая действенная метрика, поскольку напрямую измеряет способность команды реагировать.

Формула MTTR
MTTR = Общее время ...

### [Полное руководство по robots.txt для SEO и управления краулингом](https://enterno.io/articles/robots-txt-guide)
Настройка robots.txt для поисковых роботов. Синтаксис, типичные паттерны, инструменты тестирования и ошибки, которых стоит избегать.
Файл robots.txt — простой текстовый файл в корне сайта, указывающий поисковым роботам, какие страницы они могут и не могут сканировать. Несмотря на простоту, ошибки в конфигурации приводят к серьёзным SEO-проблемам — случайная блокировка всего сайта от индексации встречается чаще, чем кажется.

Как работает robots.txt
Поисковый робот при посещении сайта сначала проверяет https://example.com/robots.txt. Файл содержит директивы, указывающие разрешённые и запрещённые пути для каждого робота (user-a...

### [Мониторинг Docker-контейнеров: метрики, инструменты и лучшие практики](https://enterno.io/articles/docker-container-monitoring)
Как мониторить Docker-контейнеры: ключевые метрики, инструменты Prometheus и cAdvisor, стратегии алертинга и продакшен-практики.
Почему мониторинг контейнеров отличается
Docker-контейнеры эфемерны. Они запускаются, останавливаются, масштабируются автоматически. Контейнер, работающий сейчас, может не существовать через пять минут. Традиционный серверный мониторинг — отслеживание долгоживущих хостов со статическими IP — не работает в контейнерной среде. Нужен мониторинг, адаптирующийся к динамической инфраструктуре.
Мониторинг контейнеров должен учитывать: короткоживущие экземпляры, высокую кардинальность (сотни и тысячи ко...

### [Gzip vs Brotli: сравнение веб-компрессии](https://enterno.io/articles/gzip-brotli-compression)
Сравнение Gzip и Brotli: степень сжатия, производительность, настройка сервера и рекомендации для оптимизации скорости сайта.
Почему компрессия важна
Каждый байт, переданный по сети, стоит времени. JavaScript-бандл 500 КБ загружается 100 мс на соединении 40 Мбит/с — но сжатый до 150 КБ с Brotli загружается всего 30 мс. Умножьте на все ресурсы (HTML, CSS, JS, JSON, SVG) — компрессия может сократить время загрузки на 50–70%.
Веб-компрессия находит избыточные паттерны в текстовых файлах и заменяет их короткими представлениями. И Gzip, и Brotli — без потерь: оригинальные данные идеально восстанавливаются на стороне клиента...

### [Server-Sent Events vs WebSockets: выбор технологии реального времени](https://enterno.io/articles/server-sent-events-vs-websockets)
Сравнение SSE и WebSockets для real-time коммуникации: когда использовать каждую, производительность, масштабирование и примеры реализации.
Потребность в коммуникации реального времени
Традиционный HTTP работает по модели запрос-ответ: клиент спрашивает, сервер отвечает. Но современные веб-приложения требуют обновлений в реальном времени — live-дашборды, чат, уведомления, биржевые котировки, алерты мониторинга. Две технологии решают эту задачу: Server-Sent Events (SSE) и WebSockets. Выбор зависит от сценария использования.

Server-Sent Events (SSE)
SSE — простой протокол на основе HTTP для потоковой передачи обновлений от сервера к ...

### [Правила WAF: написание эффективных политик веб-файрвола](https://enterno.io/articles/web-application-firewall-rules)
Как писать правила WAF, избегать ложных срабатываний и защитить веб-приложение от типичных атак: SQLi, XSS, path traversal.
Что такое правила WAF?
Web Application Firewall (WAF) инспектирует HTTP/HTTPS-трафик между пользователями и вашим веб-приложением, блокируя вредоносные запросы на основе набора правил. Правила WAF определяют, какие паттерны искать и какое действие предпринять — пропустить, заблокировать, залогировать или отправить на CAPTCHA.
В отличие от сетевых файрволов (Layer 3/4), WAF работает на прикладном уровне (Layer 7). Он может инспектировать URL-пути, параметры запроса, тела POST-запросов, заголовки,...

### [DNS Failover: автоматическое переключение трафика для высокой доступности](https://enterno.io/articles/dns-failover-guide)
Как работает DNS failover, как настроить автоматическое переключение трафика и лучшие практики высокой доступности через DNS.
Что такое DNS Failover?
DNS failover — это автоматизированный механизм перенаправления трафика с неработающего сервера на работающий путём изменения DNS-ответов в реальном времени. Когда проверка здоровья обнаруживает, что основной сервер недоступен, DNS-провайдер автоматически обновляет запись, направляя на резервный сервер.
Традиционный DNS статичен — записи устанавливаются вручную. DNS failover добавляет интеллектуальный слой: непрерывный мониторинг здоровья с автоматическим переключением зап...

### [План реагирования на инциденты: пошаговое руководство для веб-команд](https://enterno.io/articles/incident-response-plan)
Как создать эффективный план реагирования на инциденты: фазы, роли, шаблоны коммуникации и процесс пост-инцидентного разбора.
Зачем нужен план реагирования на инциденты
Инциденты случаются. Серверы падают, деплои ломают продакшен, базы данных повреждаются, SSL-сертификаты истекают, DNS-пропагация не работает, а DDoS-атаки приходят в 3 часа ночи. Разница между командами, которые справляются хорошо, и командами, которые впадают в хаос — не в технических навыках, а в подготовке.
План реагирования на инциденты (IRP) — это документированный процесс, определяющий, что происходит при сбое. Он описывает, кто отвечает, как течё...

### [Структурированные данные для SEO: руководство по Schema.org](https://enterno.io/articles/structured-data-seo)
Как внедрить Schema.org для улучшения поисковой выдачи: расширенные сниппеты, панели знаний и повышение видимости сайта.
Что такое структурированные данные?
Структурированные данные — это стандартизированный формат предоставления информации о странице и классификации её контента. Используется словарь Schema.org — совместный проект Google, Bing, Yahoo и Яндекса — чтобы помочь поисковым системам понять не только что на странице, а что это означает.
Без структурированных данных поисковик видит текст и должен извлечь смысл из контекста. Со структурированными данными вы явно сообщаете: «Это товар стоимостью 4999 руб., ...

### [SSL Pinning: что это и когда использовать](https://enterno.io/articles/ssl-pinning-explained)
Разбираем SSL/TLS пиннинг сертификатов: принцип работы, методы реализации, преимущества безопасности и подводные камни.
Что такое SSL Pinning?
SSL pinning (пиннинг сертификатов) — это техника безопасности, при которой приложение принимает только определённые сертификаты или публичные ключи при подключении к серверу, а не доверяет любому сертификату, подписанному доверенным центром сертификации (CA).
В стандартном TLS доверие иерархическое: браузер или ОС доверяют набору корневых CA (~150 на большинстве систем), и любой сертификат, подписанный ими (или их посредниками), принимается. Это удобно, но создаёт большую ...

### [Пул соединений с БД: как работает и лучшие практики](https://enterno.io/articles/database-connection-pooling)
Разбираем пулы соединений с базой данных: принцип работы, настройка для MySQL и PostgreSQL, формула оптимального размера и типичные ошибки.
Зачем нужен пул соединений
Каждый запрос к базе данных требует соединения. Создание нового соединения включает TCP-handshake, аутентификацию, выделение памяти на сервере БД и инициализацию сессии. Для MySQL это занимает 5–50 мс. Для PostgreSQL — 50–100 мс из-за форка процесса. Умножьте это на тысячи запросов в секунду, и накладные расходы на соединения становятся серьёзным узким местом.
Пул соединений решает эту проблему, поддерживая набор заранее установленных соединений, которые разделяются ме...

### [Latency и Throughput: ключевые метрики производительности сети](https://enterno.io/articles/latency-vs-throughput)
Разбираем разницу между задержкой (latency) и пропускной способностью (throughput), их влияние на производительность и методы оптимизации.
Что такое Latency и Throughput?
Latency (задержка) и throughput (пропускная способность) — две фундаментальные метрики производительности сети и приложений. Хотя они связаны, они измеряют разные аспекты работы системы. Путаница между ними — распространённая ошибка, которая ведёт к неэффективной оптимизации и плохому пользовательскому опыту.
Latency — это время, необходимое одной единице данных (пакету, запросу, сообщению) для перемещения от источника к получателю. Измеряется в миллисекундах (мс)...

### [Оптимизация производительности Nginx: ключевые настройки](https://enterno.io/articles/nginx-performance-tuning)
Настройка Nginx для максимальной производительности — worker-процессы, обработка соединений, gzip, кэширование, буферы и оптимизация SSL.
Nginx — один из самых популярных веб-серверов и обратных прокси, известный высокой производительностью и низким потреблением ресурсов. Однако конфигурация по умолчанию консервативна и рассчитана на работу на любом оборудовании. Настройка Nginx под конкретную нагрузку может значительно повысить пропускную способность, снизить задержку и обработать больше одновременных соединений.

Worker-процессы и соединения
Самые фундаментальные параметры настройки определяют количество воркеров и число соедине...

### [Чеклист миграции сайта: избегаем потери SEO и простоев](https://enterno.io/articles/website-migration-checklist)
Полный чеклист миграции сайта — сохранение SEO-позиций, предотвращение простоев, настройка редиректов, DNS и пост-миграционный мониторинг.
Миграция сайта — смена домена, переезд на другой хостинг, реструктуризация URL или переход на HTTPS — одна из самых рискованных операций в веб-управлении. При неправильном выполнении она может уничтожить позиции в поисковых системах, сломать входящие ссылки и вызвать длительный простой. Этот чеклист охватывает каждую фазу успешной миграции с минимальным ущербом для пользователей и поисковой видимости.

Типы миграции сайта

Тип миграцииУровень рискаВлияние на SEOПример
Смена доменаОчень высокийЗн...

### [Стратегии деплоя без простоя](https://enterno.io/articles/zero-downtime-deployment)
Стратегии развёртывания без простоя — blue-green, rolling, canary. Миграции базы данных и обеспечение непрерывной доступности сервиса.
Развёртывание без простоя (zero-downtime deployment) — практика выпуска новых версий приложения без какого-либо прерывания работы для конечных пользователей. В мире, где даже секунды простоя означают потерю дохода, ущерб репутации и нарушение SLA, владение техниками деплоя без простоя необходимо для любого продакшен-сервиса.

Почему при деплое возникает простой
Традиционное развёртывание вызывает простой, потому что приложение нужно остановить для замены кода и перезапустить для загрузки новой в...

### [Алгоритмы балансировки нагрузки: Round Robin, Least Connections и другие](https://enterno.io/articles/load-balancing-algorithms)
Обзор алгоритмов балансировки нагрузки: round robin, least connections, weighted, IP hash и другие. Когда и какой алгоритм использовать.
Балансировка нагрузки распределяет входящий сетевой трафик между несколькими серверами, чтобы ни один из них не был перегружен. Алгоритм распределения напрямую влияет на производительность приложения, надёжность и использование ресурсов. Выбор правильного алгоритма зависит от паттернов трафика, возможностей серверов и архитектуры приложения.

Зачем нужна балансировка нагрузки
Без балансировки нагрузки один сервер обрабатывает все запросы — это единая точка отказа и ограничение масштабирования. Б...

### [TLS 1.3: что изменилось и почему это важно](https://enterno.io/articles/tls-1-3-improvements)
Улучшения TLS 1.3 по сравнению с предыдущими версиями — быстрые рукопожатия, усиленная безопасность и сниженная задержка для веб-приложений.
TLS 1.3 — последняя версия протокола Transport Layer Security, утверждённая в RFC 8446 в августе 2018 года. Это самое значительное обновление протокола TLS с момента его создания: удалены устаревшие криптографические алгоритмы, упрощено рукопожатие и значительно улучшены безопасность и производительность. Для всех, кто управляет веб-сервисами, понимание TLS 1.3 необходимо для поддержания безопасной и быстрой инфраструктуры.

Рукопожатие TLS: сравнение 1.2 и 1.3
Самое заметное улучшение TLS 1.3 —...

### [DNS over HTTPS (DoH): конфиденциальность, безопасность и принцип работы](https://enterno.io/articles/dns-over-https)
Как DNS over HTTPS шифрует DNS-запросы, улучшает конфиденциальность, предотвращает манипуляции и что это значит для безопасности сети.
DNS over HTTPS (DoH) — протокол, который шифрует DNS-запросы, отправляя их через HTTPS-соединения к DNS-резолверу. Традиционный DNS передаёт запросы в открытом виде по UDP-порту 53, делая их видимыми для любого наблюдателя сетевого трафика — провайдеров, сетевых администраторов и злоумышленников. DoH оборачивает DNS-запросы в стандартный HTTPS-трафик на порту 443, делая их неотличимыми от обычного веб-сёрфинга.

Проблемы традиционного DNS
Стандартный DNS (RFC 1035) имеет несколько проблем с конф...

### [HTTP-методы: GET, POST, PUT, DELETE и другие](https://enterno.io/articles/http-methods-explained)
Полное руководство по HTTP-методам — GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Семантика, применение и лучшие практики для REST API.
HTTP-методы (HTTP-глаголы) определяют действие, которое необходимо выполнить над ресурсом по указанному URL. Они являются основой проектирования RESTful API и необходимы для корректного взаимодействия клиента и сервера. Понимание HTTP-методов критично для создания, использования и мониторинга веб-API.

Обзор HTTP-методов

МетодНазначениеТело запросаБезопасныйИдемпотентныйКэшируемый
GETПолучить ресурсНетДаДаДа
POSTСоздать ресурс или выполнить действиеДаНетНетРедко
PUTПолностью заменить ресурсДаНе...

### [CORS: руководство по Cross-Origin Resource Sharing](https://enterno.io/articles/cors-explained)
Как работает CORS — кросс-доменные запросы, preflight-проверки, заголовки, типичные ошибки и правильная настройка для вашего веб-приложения.
Cross-Origin Resource Sharing (CORS) — механизм безопасности, встроенный в веб-браузеры, который контролирует, как веб-страницы с одного источника (домен, протокол, порт) могут запрашивать ресурсы с другого источника. Без CORS браузеры применяют политику одного источника (Same-Origin Policy, SOP), блокируя кросс-доменные HTTP-запросы из JavaScript. CORS предоставляет безопасный, стандартизированный способ ослабить это ограничение при необходимости.

Политика одного источника (Same-Origin Policy)...

### [Обратный прокси: как работает и зачем нужен](https://enterno.io/articles/reverse-proxy-explained)
Узнайте, как работает обратный прокси-сервер, его преимущества для безопасности, производительности и масштабируемости, и как настроить Nginx.
Обратный прокси (reverse proxy) — это сервер, расположенный между клиентскими устройствами и бэкенд-серверами. Он принимает запросы клиентов, перенаправляет их на соответствующий бэкенд и возвращает ответ клиенту. В отличие от прямого прокси (который действует от имени клиентов), обратный прокси действует от имени серверов, обеспечивая единую точку входа для распределённой инфраструктуры.

Как работает обратный прокси
Когда клиент отправляет HTTP-запрос, он сначала попадает на обратный прокси. П...

### [TCP vs UDP: различия, применение и производительность](https://enterno.io/articles/tcp-udp-difference)
Ключевые различия между TCP и UDP, области применения, характеристики производительности и выбор протокола для ваших приложений.
TCP (Transmission Control Protocol) и UDP (User Datagram Protocol) — два фундаментальных протокола транспортного уровня в интернете. Каждое сетевое приложение использует один из них или оба для передачи данных между хостами. Понимание их различий необходимо для принятия обоснованных архитектурных решений о надёжности, задержке и пропускной способности.

Как работает TCP
TCP — протокол с установлением соединения. Перед обменом данными клиент и сервер выполняют трёхстороннее рукопожатие для создан...

### [Мониторинг крон-заданий: Dead Man's Switch](https://enterno.io/articles/cron-job-monitoring)
Как мониторить cron-задачи: Dead Man's Switch, heartbeat мониторинг, обнаружение пропущенных и зависших задач.
Проблема невидимых сбоев
Cron-задачи работают в фоне: обработка платежей, рассылка email, генерация отчётов, очистка данных, резервное копирование. Когда крон-задача молча падает или зависает, об этом узнают через часы, дни или даже недели — когда клиенты начинают жаловаться.
Мониторинг крон-задач — это не проверка «работает ли сервер», а проверка «выполнилась ли задача в ожидаемое время».

Dead Man's Switch — принцип работы
Dead Man's Switch (DMS) — паттерн мониторинга, инвертирующий обычную ло...

### [Метрики производительности API](https://enterno.io/articles/api-performance-metrics)
Ключевые метрики производительности API: латентность, throughput, error rate, percentiles. Как измерять и оптимизировать.
Зачем измерять производительность API
API — основа современных веб-приложений. Медленный API означает медленный сайт, плохой пользовательский опыт и потерю клиентов. По данным Amazon, каждые 100 мс задержки снижают продажи на 1%. Для API, обслуживающих фронтенд, это критично.
Без метрик вы не знаете, насколько быстро работает API, где узкие места и когда начинается деградация.

Ключевые метрики

Latency (задержка)
Время от отправки запроса до получения ответа. Главная метрика пользовательского о...

### [Редиректы и SEO: 301, 302, canonical](https://enterno.io/articles/redirects-seo-guide)
Как редиректы влияют на SEO: 301 vs 302, цепочки редиректов, canonical tag, миграция URL. Практическое руководство.
Как редиректы влияют на SEO
Редиректы направляют пользователей и поисковых роботов с одного URL на другой. Правильно настроенные редиректы сохраняют SEO-вес и обеспечивают корректную индексацию. Неправильные — размывают ссылочный вес, замедляют краулинг и приводят к потере позиций.

Типы редиректов

301 — Moved Permanently
Постоянный редирект. Сообщает поисковым системам, что страница переехала навсегда. Передаёт максимальный SEO-вес (ссылочный профиль) на новый URL. Google обрабатывает 301 как ...

### [Мониторинг SSL-сертификатов: избегаем простоев](https://enterno.io/articles/ssl-certificate-monitoring)
Как мониторить SSL-сертификаты: автопродление, сроки истечения, цепочка доверия, уведомления. Предотвращение даунтайма.
Почему истекший сертификат — катастрофа
Когда SSL-сертификат истекает, браузеры показывают полноэкранное предупреждение, блокируя доступ к сайту. Пользователи не могут обойти это предупреждение без специальных действий. Результат: потеря трафика, конверсий и доверия. По статистике, 85% пользователей покидают сайт при виде SSL-ошибки.
Истечение сертификата — самая предотвратимая причина даунтайма. Вы всегда знаете дату истечения заранее.

Что мониторить

Срок действия
Главная метрика — количество...

### [CDN: как работает и зачем нужен](https://enterno.io/articles/cdn-how-it-works)
Как работает Content Delivery Network: edge-серверы, кэширование, anycast маршрутизация. Когда CDN нужен и как выбрать.
Что такое CDN
Content Delivery Network (CDN) — это распределённая сеть серверов, расположенных по всему миру. Вместо того чтобы загружать контент с одного origin-сервера, пользователь получает его с ближайшего edge-сервера CDN. Это сокращает расстояние, которое проходят данные, и как следствие — уменьшает задержку.
Если ваш сервер в Москве, а пользователь в Токио, данные проходят ~9000 км. С CDN пользователь из Токио получает контент с edge-сервера в Японии — расстояние сокращается до сотен кило...

### [SEO-аудит сайта: чеклист из 20 пунктов](https://enterno.io/articles/seo-audit-checklist)
Практический чеклист SEO-аудита: 20 пунктов для проверки технического SEO, контента, производительности и безопасности.
Зачем нужен SEO-аудит
SEO-аудит — систематическая проверка сайта на соответствие требованиям поисковых систем. Он выявляет технические ошибки, проблемы с контентом и производительностью, которые мешают ранжированию. Проводите аудит минимум раз в квартал и после каждого крупного обновления сайта.

Техническое SEO

1. HTTPS
Сайт должен работать по HTTPS. Все HTTP-URL должны возвращать 301 редирект на HTTPS. Проверьте с помощью SSL-чекера Enterno.io.

2. Скорость загрузки
Время загрузки должно быть...

### [Заголовки безопасности: полный гайд](https://enterno.io/articles/security-headers-complete-guide)
Полное руководство по заголовкам HTTP-безопасности: CSP, HSTS, X-Frame-Options, Permissions-Policy, CORP, COEP. Настройка и примеры.
Зачем нужны заголовки безопасности
Заголовки безопасности HTTP — инструкции для браузера, определяющие правила безопасности при работе с вашим сайтом. Они защищают от XSS, clickjacking, MITM, инъекций и других атак. Настройка занимает минуты, а эффект — закрытие целых классов уязвимостей.
Проверьте текущие заголовки безопасности вашего сайта с помощью сканера безопасности Enterno.io.

Content-Security-Policy (CSP)
CSP — самый мощный заголовок безопасности. Он определяет, откуда могут загружаться...

### [HTTP/2 vs HTTP/3: что нового и зачем переходить](https://enterno.io/articles/http2-http3-comparison)
Сравнение HTTP/2 и HTTP/3: QUIC, мультиплексирование, 0-RTT, миграция соединений. Практическое руководство по переходу.
Эволюция HTTP
HTTP/1.1 служил вебу более 15 лет, но его ограничения — блокировка head-of-line, максимум 6 параллельных соединений на домен — тормозили развитие. HTTP/2 (2015) решил многие проблемы, а HTTP/3 (2022) переписал транспортный уровень с нуля, перейдя с TCP на QUIC.

HTTP/2: ключевые улучшения

Мультиплексирование
HTTP/2 позволяет передавать множество запросов и ответов параллельно через одно TCP-соединение. В HTTP/1.1 для параллельности нужны отдельные соединения (до 6 на домен).

Сжат...

### [Мониторинг uptime: зачем и как настроить](https://enterno.io/articles/uptime-monitoring-guide)
Полное руководство по мониторингу uptime: зачем нужен, как настроить, выбор инструментов, SLA и status pages.
Зачем мониторить uptime
Uptime (доступность) — время, в течение которого сайт или сервис доступен и функционирует корректно. Каждая минута простоя — это потерянные деньги, клиенты и репутация. По исследованиям, одна минута простоя обходится бизнесу в среднем в $5,600 для крупных компаний.
Мониторинг uptime позволяет обнаружить проблему за минуты, а не узнать о ней от недовольных клиентов через часы.

Что мониторить

Основной сайт
Проверяйте главную страницу и ключевые разделы. Не ограничивайтесь...

### [DNS и производительность: оптимизация резолвинга](https://enterno.io/articles/dns-performance-optimization)
Как ускорить DNS-резолвинг: выбор DNS-провайдера, TTL, prefetch, минимизация lookups. Влияние DNS на скорость сайта.
Влияние DNS на скорость загрузки
Каждый HTTP-запрос начинается с DNS-резолвинга — преобразования доменного имени в IP-адрес. Этот процесс занимает от 20 до 120 мс, а при первом обращении к домену — до 200-300 мс. На странице с ресурсами из 10 разных доменов DNS-lookups могут добавить до 1-2 секунд к загрузке.
DNS-резолвинг — часто упускаемый из виду фактор производительности, который можно оптимизировать без изменения кода.

Как работает DNS-резолвинг

Браузер проверяет свой DNS-кэш
Если не найд...

### [Влияние HTTPS на SEO и ранжирование](https://enterno.io/articles/https-seo-impact)
Как переход на HTTPS влияет на SEO, ранжирование в Google, доверие пользователей. Пошаговая миграция с HTTP на HTTPS.
HTTPS как фактор ранжирования
Google официально подтвердил HTTPS как фактор ранжирования ещё в 2014 году. С тех пор его вес только увеличивался. Сегодня более 95% результатов на первой странице Google используют HTTPS. Отсутствие HTTPS — это не просто минус к ранжированию, это знак для пользователей что сайту нельзя доверять.

Влияние HTTPS на SEO

Прямое влияние на ранжирование
HTTPS — лёгкий, но стабильный сигнал ранжирования. Google использует его как «тай-брейк»: при прочих равных условиях H...

### [Core Web Vitals: полное руководство](https://enterno.io/articles/core-web-vitals-guide)
Подробный гайд по Core Web Vitals: LCP, INP, CLS. Как измерить, улучшить и влиять на SEO-ранжирование.
Что такое Core Web Vitals
Core Web Vitals — набор метрик от Google, измеряющих реальный пользовательский опыт на сайте. С 2021 года они являются фактором ранжирования в Google. Три основные метрики оценивают скорость загрузки, интерактивность и визуальную стабильность.

LCP — Largest Contentful Paint
LCP измеряет время загрузки самого крупного видимого элемента контента на первом экране. Это может быть изображение, видео, блок текста или фоновое изображение через CSS.

Целевые значения

Хорошо: ...

### [Стратегии кэширования веб-приложений](https://enterno.io/articles/web-caching-strategies)
Уровни кэширования веб-приложений: браузер, CDN, прокси, серверный кэш, база данных. Стратегии инвалидации и паттерны.
Зачем нужна стратегия кэширования
Кэширование — самый мощный инструмент оптимизации производительности. Правильная стратегия кэширования может снизить нагрузку на сервер на 90%, уменьшить время отклика в 10-100 раз и значительно сэкономить на инфраструктуре. Но кэширование без стратегии приводит к устаревшим данным, багам и сложной отладке.

Уровни кэширования

1. Браузерный кэш (клиентский)
Самый близкий к пользователю уровень. Управляется HTTP-заголовками Cache-Control, ETag, Expires. Нулевая ...

### [Оптимизация изображений для веба](https://enterno.io/articles/image-optimization-web)
Как оптимизировать изображения для веб-сайтов: форматы WebP и AVIF, lazy loading, responsive images, сжатие без потери качества.
Почему изображения — главная проблема производительности
Изображения составляют в среднем 50-70% от общего веса веб-страницы. По данным HTTP Archive, средняя страница загружает более 1 МБ изображений. Неоптимизированные изображения — причина №1 медленной загрузки сайтов и плохих показателей Core Web Vitals.
Оптимизация изображений — это самый быстрый способ ускорить сайт с минимальными усилиями.

Современные форматы изображений

WebP
Формат от Google, поддерживается всеми современными браузерами...

### [Rate Limiting в API: зачем и как настроить](https://enterno.io/articles/api-rate-limiting)
Полное руководство по Rate Limiting в API: алгоритмы, реализация, заголовки, best practices. Защита API от злоупотреблений.
Зачем нужен Rate Limiting
Rate Limiting — механизм ограничения количества запросов к API за определённый период времени. Без него ваш API уязвим к нескольким проблемам:

DDoS и brute-force атаки — злоумышленник может отправлять тысячи запросов в секунду
Парсинг и скрейпинг — боты могут массово выгружать данные
Случайные перегрузки — баг в клиентском коде может вызвать лавину запросов
Несправедливое использование — один клиент может занять все ресурсы сервера

Rate Limiting защищает сервер, обесп...

### [Лучшие практики алертинга для мониторинга сайтов](https://enterno.io/articles/alerting-best-practices)
Как настроить эффективные алерты: пороги, каналы уведомлений, эскалация, подавление шума. Избегаем alert fatigue.
Проблема Alert Fatigue
Alert fatigue — главный враг эффективного мониторинга. Когда команда получает сотни уведомлений в день, важные алерты теряются среди шума. По данным исследований, до 70% алертов игнорируются в командах с неправильно настроенным мониторингом.
Цель алертинга — уведомить правильного человека о правильной проблеме в правильное время. Не больше и не меньше.

Принципы эффективного алертинга

Алерт должен требовать действия
Каждый алерт должен подразумевать конкретное действие. Е...

### [Синтетический мониторинг vs RUM: сравнение подходов](https://enterno.io/articles/synthetic-vs-rum-monitoring)
Сравнение синтетического мониторинга и Real User Monitoring (RUM). Когда использовать каждый подход, плюсы и минусы, примеры.
Два подхода к мониторингу производительности
Мониторинг производительности сайта делится на два фундаментальных подхода: синтетический мониторинг и Real User Monitoring (RUM). Они решают разные задачи и дают разные данные. Понимание различий поможет выбрать правильную стратегию для вашего проекта.

Синтетический мониторинг
Синтетический мониторинг использует автоматизированные скрипты, которые имитируют действия пользователя. Тесты запускаются по расписанию из фиксированных точек (дата-центров) ...

### [WAF: что это и как защищает сайт](https://enterno.io/articles/what-is-waf)
Что такое Web Application Firewall (WAF), как он работает, от каких атак защищает. Типы WAF, настройка и лучшие практики.
Что такое WAF
Web Application Firewall (WAF) — это защитный экран, который фильтрует HTTP-трафик между интернетом и вашим веб-приложением. В отличие от обычного файрвола, который работает на сетевом уровне (IP-адреса и порты), WAF анализирует содержимое HTTP-запросов и ответов, блокируя вредоносные паттерны.
WAF работает на 7 уровне модели OSI (прикладной уровень) и понимает специфику веб-протоколов: HTTP-методы, заголовки, cookies, параметры URL и тело запроса.

От каких атак защищает WAF

SQL-...

### [Безопасность cookies: HttpOnly, Secure, SameSite](https://enterno.io/articles/cookie-security-flags)
Разбираем флаги безопасности cookies: HttpOnly, Secure, SameSite. Как защитить сессии пользователей от XSS, CSRF и перехвата.
Почему безопасность cookies критически важна
Cookies — основной механизм хранения сессий и аутентификации в вебе. Неправильно настроенные cookies открывают двери для атак: кража сессий через XSS, подделка запросов через CSRF, перехват данных при передаче по HTTP. Три ключевых флага — HttpOnly, Secure и SameSite — закрывают большинство этих уязвимостей.

Флаг HttpOnly
Флаг HttpOnly запрещает доступ к cookie из JavaScript. Браузер отправляет cookie с HTTP-запросами, но document.cookie не видит её....

### [HTTP кэширование: Cache-Control, ETag, Expires](https://enterno.io/articles/http-caching-guide)
Подробное руководство по HTTP кэшированию: заголовки Cache-Control, ETag, Expires, Last-Modified. Как настроить кэширование для ускорения сайта.
Зачем нужно HTTP кэширование
HTTP кэширование — один из самых эффективных способов ускорить загрузку сайта. Когда браузер сохраняет копию ресурса локально, повторные запросы обрабатываются мгновенно, без обращения к серверу. Это снижает нагрузку на сервер, уменьшает потребление трафика и значительно улучшает пользовательский опыт.
По данным Google, уменьшение времени загрузки на 100 мс увеличивает конверсию на 1%. Правильно настроенное кэширование может сократить время загрузки повторных визитов...

### [DNSSEC: как работает защита DNS и зачем она нужна](https://enterno.io/articles/dnssec-explained)
Что такое DNSSEC, как он защищает от подмены DNS-ответов. Принцип работы, цепочка доверия, типы записей RRSIG, DNSKEY, DS. Как проверить и настроить.
DNS (Domain Name System) по умолчанию не обеспечивает проверку подлинности ответов. Это означает, что злоумышленник может подменить DNS-ответ и перенаправить пользователя на фишинговый сайт. DNSSEC решает эту проблему, добавляя криптографическую подпись к DNS-записям.

Проблема: DNS без защиты
Стандартный DNS работает по протоколу UDP без шифрования и аутентификации. Это делает его уязвимым к нескольким типам атак:

DNS Cache Poisoning
Злоумышленник отправляет поддельные DNS-ответы рекурсивному ...

### [Uptime сайта и SLA: что означают 99.9% и как считать доступность](https://enterno.io/articles/website-uptime-sla)
Что такое uptime и SLA сайта. Разница между 99.9% и 99.99%, как рассчитать допустимое время простоя, инструменты мониторинга доступности.
Uptime (аптайм) — это процент времени, в течение которого сайт или сервис доступен и работает корректно. Для бизнеса каждая минута простоя — это потерянные клиенты, упущенная выручка и ущерб репутации.

Что такое SLA
SLA (Service Level Agreement) — соглашение об уровне обслуживания, в котором поставщик гарантирует определённый уровень доступности. Например, SLA 99.9% означает, что сервис может быть недоступен не более 8 часов 45 минут за год.

Таблица уровней доступности
Разница между «девятками...

### [HTTP/2 и HTTP/3: чем отличаются и что быстрее](https://enterno.io/articles/http2-vs-http3)
Сравнение протоколов HTTP/2 и HTTP/3: мультиплексирование, QUIC, head-of-line blocking, производительность. Как проверить и настроить.
Протокол HTTP — основа современного веба. Эволюция от HTTP/1.1 к HTTP/2 и HTTP/3 принесла значительные улучшения производительности. Понимание различий между этими версиями помогает правильно настроить сервер и ускорить загрузку сайта.

Краткая история HTTP

  ВерсияГодТранспортКлючевое нововведение
  HTTP/1.01996TCPБазовый протокол
  HTTP/1.11997TCPKeep-alive, chunked transfer, Host header
  HTTP/22015TCP + TLSМультиплексирование, сжатие заголовков, server push
  HTTP/32022QUIC (UDP)Устранение ...

### [Открытые порты сервера: как проверить и почему это важно для безопасности](https://enterno.io/articles/open-ports-security)
Руководство по проверке открытых портов: TCP/UDP, популярные порты, инструменты сканирования, риски безопасности и рекомендации по защите.
Сетевые порты — это виртуальные точки входа, через которые приложения на сервере принимают сетевые соединения. Каждый открытый порт — это потенциальная точка атаки. Понимание того, какие порты открыты на вашем сервере и зачем, — фундамент сетевой безопасности.

Как работают сетевые порты
IP-адрес идентифицирует сервер в сети, а порт — конкретное приложение на этом сервере. Вместе они образуют сокет (socket), например 93.184.216.34:443. Всего существует 65 535 портов, разделённых на три диапазона...

### [WHOIS: как узнать информацию о домене и зачем это нужно](https://enterno.io/articles/whois-lookup-guide)
Полное руководство по WHOIS-запросам: как узнать владельца домена, дату регистрации, сроки истечения. Примеры, инструменты и практическое применение.
WHOIS — это протокол и база данных, которая хранит информацию о регистрации доменных имён. С помощью WHOIS-запроса можно узнать, кому принадлежит домен, когда он был зарегистрирован, когда истекает, и через какого регистратора обслуживается.

Что такое WHOIS
WHOIS (от английского «who is» — «кто это») — публичный реестр информации о доменах. Когда вы регистрируете домен, ваши данные (или данные вашей организации) записываются в базу WHOIS. Этот реестр поддерживается организацией ICANN и регионал...

### [DNS Propagation — почему изменения DNS не работают сразу](https://enterno.io/articles/dns-propagation)
Что такое DNS-пропагация, почему изменения DNS не применяются мгновенно, как проверить распространение DNS и ускорить процесс. Практическое руководство.
Вы сменили хостинг, обновили A-запись или перенесли домен — но сайт по-прежнему открывается со старого сервера. Знакомая ситуация? Это DNS-пропагация — процесс распространения изменений DNS по серверам по всему миру. В этой статье разберём, как это работает и что делать, чтобы не ждать двое суток.

Что такое DNS-пропагация

DNS-пропагация (DNS propagation) — это время, которое требуется для распространения изменений DNS-записей по всем DNS-серверам в интернете. Когда вы меняете запись у регистра...

### [Мониторинг сайта — зачем нужен и как правильно настроить](https://enterno.io/articles/website-monitoring-guide)
Полное руководство по мониторингу сайтов: uptime, SSL, DNS, скорость. Как выбрать интервал проверки, настроить алерты и не пропустить сбой.
Мониторинг сайта — это непрерывное автоматическое отслеживание доступности, производительности и корректной работы веб-ресурса. Без мониторинга вы узнаёте о проблемах последними: от пользователей, из поисковой консоли или по падению выручки. С мониторингом — в ту же минуту, когда что-то пошло не так.

Зачем нужен мониторинг

Среднее время обнаружения проблемы без мониторинга — от 30 минут до нескольких часов. С мониторингом — от 1 до 5 минут. За это время бизнес теряет:


Посетителей и конверсии...

### [Content Security Policy (CSP) — полное руководство по настройке](https://enterno.io/articles/csp-guide)
Что такое Content Security Policy, как настроить CSP-заголовок, какие директивы использовать. Примеры конфигураций и типичные ошибки.
Content Security Policy (CSP) — это заголовок безопасности, который указывает браузеру, откуда разрешено загружать ресурсы: скрипты, стили, изображения, шрифты, фреймы и другие. CSP — один из самых мощных инструментов защиты от XSS-атак (Cross-Site Scripting), инъекций кода и clickjacking.

Зачем нужен CSP

XSS остаётся одной из самых распространённых веб-уязвимостей по версии OWASP Top 10. Даже при тщательной фильтрации пользовательского ввода существует риск пропустить вектор атаки. CSP работа...

### [Как проверить SSL-сертификат сайта: пошаговое руководство](https://enterno.io/articles/check-ssl-certificate)
Как проверить SSL-сертификат сайта: срок действия, цепочку доверия, протоколы TLS, уязвимости. Онлайн-инструменты и командная строка.
SSL-сертификат — это цифровой документ, который подтверждает подлинность сайта и обеспечивает шифрование данных между браузером и сервером. Проверка SSL-сертификата помогает убедиться, что соединение защищено, сертификат действителен и правильно настроен.

Почему важно проверять SSL-сертификат

Просроченный или неправильно настроенный сертификат — это не просто техническая проблема:

Потеря посетителей — браузеры показывают предупреждение «Подключение не защищено», и 85% пользователей немедленно...

### [HSTS — что это такое и зачем нужен вашему сайту](https://enterno.io/articles/hsts-guide)
Что такое HSTS (HTTP Strict Transport Security), как он защищает от атак, как настроить заголовок и избежать типичных ошибок. Практическое руководство.
HSTS (HTTP Strict Transport Security) — это механизм безопасности, который сообщает браузеру: «Этот сайт должен загружаться только по HTTPS. Никогда не используй HTTP». После получения заголовка HSTS браузер автоматически перенаправляет все HTTP-запросы на HTTPS, даже если пользователь вручную ввёл адрес без https://.

Зачем нужен HSTS

Вы настроили SSL-сертификат, добавили редирект с HTTP на HTTPS — казалось бы, достаточно. Но без HSTS остаётся уязвимость: первый запрос пользователя может уйти ...

### [Массовая проверка URL: автоматизация мониторинга сайтов](https://enterno.io/articles/batch-url-checking)
Как проверить сотни URL одновременно: массовая проверка HTTP-кодов, заголовков, редиректов. Инструменты и автоматизация.
Когда у вас один сайт с десятком страниц, ручная проверка HTTP-заголовков и кодов ответа — не проблема. Но что делать, если нужно проверить сотни URL после миграции, запуска нового сайта или массового обновления контента? Массовая проверка URL позволяет автоматизировать этот процесс и быстро находить проблемы.

Когда нужна массовая проверка

Миграция сайта

При переносе сайта на новую CMS, смене домена или изменении структуры URL критически важно убедиться, что все старые адреса корректно перена...

### [Точность IP-геолокации: как это работает и где ошибается](https://enterno.io/articles/ip-geolocation-accuracy)
Как работает IP-геолокация, от чего зависит точность определения местоположения и почему VPN и прокси вносят ошибки.
IP-геолокация — технология определения географического местоположения устройства по его IP-адресу. Она используется повсеместно: для таргетированной рекламы, локализации контента, защиты от мошенничества, соблюдения лицензионных ограничений и аналитики посещений. Но насколько точна эта технология и где она даёт сбои?

Принцип работы IP-геолокации

Источники данных

Провайдеры GeoIP-баз данных собирают информацию из множества источников:


Реестры RIR — региональные интернет-регистраторы (RIPE NC...

### [DNS-пропагация: почему изменения DNS не применяются мгновенно](https://enterno.io/articles/dns-propagation-explained)
Почему DNS-изменения не применяются сразу: TTL, кеширование, рекурсивные резолверы. Как ускорить DNS-пропагацию.
Каждый веб-разработчик и администратор сталкивался с ситуацией: вы изменили DNS-запись, но через час (или даже сутки) часть пользователей всё ещё видит старый сайт. Это явление называется DNS-пропагацией — процессом распространения изменений DNS по всей глобальной сети. Разберём, почему это происходит и как с этим работать.

Как работает DNS

Прежде чем понять пропагацию, нужно вспомнить, как работает разрешение DNS-имён.

Иерархия DNS

DNS — это распределённая иерархическая система. Когда вы вв...

### [Типы SSL-сертификатов: DV, OV, EV — какой выбрать](https://enterno.io/articles/ssl-certificate-types)
Сравнение типов SSL-сертификатов: DV, OV, EV, Wildcard, мультидоменные. Когда нужен Let's Encrypt, а когда платный сертификат.
SSL-сертификат — обязательный атрибут современного сайта. Без него браузеры показывают предупреждение «Не защищено», поисковые системы понижают позиции, а пользователи теряют доверие. Но SSL-сертификаты бывают разных типов, и выбор правильного варианта зависит от потребностей вашего бизнеса.

Уровни валидации SSL-сертификатов

DV — Domain Validation (проверка домена)

DV-сертификат подтверждает только то, что вы контролируете домен. Центр сертификации проверяет это через один из методов: размеще...

### [Анализ серверных заголовков ответа: что они говорят о сайте](https://enterno.io/articles/server-response-headers-analysis)
Подробный разбор HTTP-заголовков: Cache-Control, ETag, Server, CORS, безопасность. Как читать и оптимизировать заголовки.
HTTP-заголовки — это метаданные, которые сервер отправляет вместе с ответом. Они управляют кешированием, безопасностью, аутентификацией, сжатием и многими другими аспектами работы сайта. Умение читать и анализировать заголовки — важный навык для веб-разработчика, SEO-специалиста и системного администратора.

Категории HTTP-заголовков

Заголовки ответа можно разделить на несколько основных категорий:



КатегорияПримерыНазначение


КешированиеCache-Control, ETag, Expires, Last-ModifiedУправление ...

### [Цепочки редиректов: как они влияют на SEO и скорость](https://enterno.io/articles/redirect-chains-seo)
Цепочки редиректов замедляют сайт и ослабляют SEO. Узнайте разницу 301 и 302, как найти цепочки и устранить их.
Редиректы (перенаправления) — неотъемлемая часть работы с сайтами. Они нужны при переезде на новый домен, изменении структуры URL, переходе с HTTP на HTTPS. Однако неправильное использование редиректов создаёт цепочки перенаправлений, которые замедляют загрузку и вредят SEO-позициям. Разберём эту проблему подробно.

Типы HTTP-редиректов

301 — Permanent Redirect

Код 301 сообщает браузерам и поисковым системам, что страница перемещена навсегда. Поисковые системы передают ссылочный вес (link juic...

### [Безопасность API: лучшие практики защиты](https://enterno.io/articles/api-security-best-practices)
Лучшие практики защиты API: аутентификация, rate limiting, CORS, HTTPS, валидация данных и защита от основных угроз.
API (Application Programming Interface) стал основой современных веб-приложений. Через API работают мобильные приложения, SPA-сайты, интеграции между сервисами и IoT-устройства. Но с ростом использования API растёт и количество атак на них. В этой статье разберём ключевые практики защиты API от наиболее распространённых угроз.

Почему безопасность API важна

По данным OWASP, API входят в топ-10 наиболее уязвимых компонентов веб-приложений. Специфика API в том, что они предоставляют прямой доступ...

### [Что такое CDN и как он ускоряет сайт](https://enterno.io/articles/what-is-cdn)
Узнайте, что такое CDN, как работают точки присутствия, и почему сеть доставки контента критически важна для скорости сайта.
CDN (Content Delivery Network) — это географически распределённая сеть серверов, которая доставляет контент пользователям с ближайшего к ним узла. Если ваш сервер находится в Москве, а пользователь — во Владивостоке, CDN позволяет отдать контент с сервера в Хабаровске или Владивостоке, сократив задержку в несколько раз.

Как работает CDN

Принцип работы CDN основан на нескольких ключевых технологиях:

Точки присутствия (PoP)

CDN состоит из множества серверов (edge-серверов), расположенных в дат...

### [Мониторинг доменов и сайтов: зачем и как настроить](https://enterno.io/articles/domain-monitoring-guide)
Руководство по мониторингу сайтов: uptime, SSL-сертификаты, DNS-изменения, ping-проверки. Как вовремя узнать о проблемах.
Мониторинг сайтов и доменов — это процесс непрерывного отслеживания доступности, производительности и корректной работы веб-ресурсов. Без мониторинга вы узнаёте о проблемах последними — от пользователей или, что хуже, по падению продаж. В этой статье разберём, что нужно отслеживать и как правильно настроить систему мониторинга.

Почему мониторинг критически важен

Каждая минута простоя сайта обходится бизнесу дорого. По данным Gartner, средняя стоимость минуты простоя для крупных компаний состав...

### [Оптимизация скорости загрузки сайта: полное руководство](https://enterno.io/articles/website-speed-optimization)
Узнайте, как ускорить сайт: Core Web Vitals, TTFB, LCP, CLS, оптимизация изображений, кеширование, CDN и минификация ресурсов.
Скорость загрузки сайта — один из ключевых факторов, определяющих пользовательский опыт, конверсию и позиции в поисковой выдаче. По данным Google, если страница загружается дольше 3 секунд, более 50% мобильных пользователей покидают её. В этом руководстве мы подробно разберём все аспекты оптимизации скорости — от серверной части до клиентского рендеринга.

Core Web Vitals: ключевые метрики производительности

В 2021 году Google ввёл набор метрик Core Web Vitals как официальный фактор ранжировани...

### [Типы DNS записей: A, AAAA, MX, CNAME, TXT и другие](https://enterno.io/articles/dns-records)
Подробный справочник типов DNS записей. Для чего нужна каждая запись, как настраивать, проверять и отлаживать DNS для вашего домена.
DNS (Domain Name System) — это система, которая преобразует доменные имена в IP-адреса. Когда вы вводите example.com в браузере, DNS-серверы находят соответствующий IP-адрес и направляют к нему запрос. Различные типы DNS записей отвечают за разные функции.

  Как работает DNS
  Процесс DNS-разрешения (от ввода домена до получения IP):
  
    Браузер проверяет локальный кэш DNS
    ОС проверяет свой кэш и файл hosts
    Рекурсивный резолвер (обычно провайдера или 8.8.8.8) ищет ответ
    Корневой ...

### [SSL/TLS сертификаты: как работает HTTPS](https://enterno.io/articles/ssl-tls-guide)
Как работает SSL/TLS, типы сертификатов, процесс TLS-хэндшейка, настройка Let's Encrypt, распространённые ошибки и способы их решения.
SSL/TLS — протокол шифрования, который защищает данные при передаче между браузером и сервером. HTTPS (HTTP over TLS) сегодня является стандартом для всех сайтов: браузеры помечают HTTP-сайты как небезопасные, а поисковики учитывают HTTPS как фактор ранжирования.

  SSL vs TLS — в чём разница
  SSL (Secure Sockets Layer) — оригинальный протокол, созданный Netscape в 1990-х. TLS (Transport Layer Security) — его современный наследник. SSL 2.0 и 3.0 давно устарели и уязвимы. Сегодня актуальны:
  
 ...

### [HTTP коды ответов: полный справочник с примерами](https://enterno.io/articles/http-status-codes)
Справочник всех HTTP кодов состояния от 100 до 599 с описаниями и примерами. Узнайте, что означает каждый код и как его обрабатывать.
HTTP коды состояния — это трёхзначные числа, которые сервер возвращает в ответ на запрос клиента. Они сообщают, что произошло с запросом: успех, перенаправление, ошибка клиента или сервера. Понимание кодов помогает отлаживать проблемы, настраивать мониторинг и улучшать SEO.

  Классификация кодов
  
    ДиапазонКатегорияОписание
    1xxИнформационныеЗапрос принят, обработка продолжается
    2xxУспехЗапрос выполнен успешно
    3xxПеренаправлениеТребуется дополнительное действие для завершения
   ...

### [Заголовки безопасности: CSP, HSTS, X-Frame-Options и другие](https://enterno.io/articles/security-headers)
Как защитить сайт с помощью HTTP заголовков безопасности. Настройка Content-Security-Policy, Strict-Transport-Security, X-Frame-Options и других заголовков.
HTTP заголовки безопасности — это первая линия защиты вашего сайта от распространённых веб-атак: XSS, clickjacking, MIME-sniffing и перехвата трафика. Правильная настройка занимает минуты, а защищает от большинства атак из OWASP Top 10.

  Content-Security-Policy (CSP)
  Самый мощный заголовок безопасности. CSP контролирует, откуда браузер может загружать ресурсы — скрипты, стили, шрифты, изображения, фреймы и другие:

  Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn....

### [HTTP заголовки: полное руководство](https://enterno.io/articles/http-headers)
Что такое HTTP заголовки, какие бывают типы, как работают заголовки запроса и ответа. Практические примеры и рекомендации для веб-разработчиков.
HTTP заголовки — это метаданные, которые передаются между клиентом (браузером) и сервером вместе с каждым HTTP запросом и ответом. Они определяют, как обрабатывать данные, какой контент возвращать, как кэшировать ответы и многое другое.

  Как работают HTTP заголовки
  Каждый HTTP запрос и ответ состоит из трёх частей: стартовая строка, заголовки и тело. Заголовки представляют собой пары «имя: значение», разделённые переводом строки:
  GET /api/data HTTP/1.1
Host: example.com
Accept: application...

## Тарифы

- [Free](https://enterno.io/pricing): 0 ₽/мес — 5 мониторов, интервал 5 мин, история 30 дней, все инструменты включены
- [Starter](https://enterno.io/pricing): 490 ₽/мес — 25 мониторов, интервал 1 мин, история 90 дней
- [Pro](https://enterno.io/pricing): 990 ₽/мес — 100 мониторов, интервал 30 сек, история 1 год, API, Telegram-бот
- [Business](https://enterno.io/pricing): 2490 ₽/мес — безлимит мониторов, SAML SSO, white-label отчёты, история 2 года, приоритетная поддержка