NGINX

Token validation on SSR

Account Panel

В логе NGINX, uriStem указывает путь к ресурсу, к которому пользователь пытался получить доступ и получил ошибку 404, означающую, что ресурс не найден на сервере.

• uriStem относится к части URL-адреса, которая идет после имени домена и указывает конкретный ресурс на сервере, к которому пытался получить доступ запрос.

referer указывает, что пользователь зашел из панели управления доменом, возможно, пытаясь настроить или получить доступ к чему-то, связанному с «example.com».

• referer — это поле заголовка, которое идентифицирует адрес веб-страницы, связанной с запрашиваемым ресурсом. По сути, он сообщает вам, откуда пришел пользователь до того, как попал на ресурс, который вернул ошибку 404.

Обе записи лога указывают, что ресурс по пути /test не удалось найти на момент запроса.

HTTP метод POST указывает, что это была отправка данных на сервер, которая обычно используется для отправки форм, запросов API или любых действий, при которых данные отправляются на сервер, а не просто запрашиваются.

Версия протокола HTTP/1.0, используемая для запроса, это более старый протокол HTTP, при этом HTTP/1.1 и HTTP/2 более распространены в современном просмотре веб-страниц и использовании API:

• Повторное использование соединений (Persistent Connections, постоянные соединения): HTTP/1.0 не поддерживает Persistent Connections. Это означает, что для каждой пары HTTP-запрос/ответ устанавливается новое TCP-соединение, что может привести к увеличению задержки и снижению производительности из-за затрат на установку и разрыв соединений.
• HTTP/1.1 и более поздние версии: эти версии по умолчанию поддерживают Persistent Connections. Несколько запросов и ответов могут быть отправлены по одному TCP-соединению, что снижает задержку и накладные расходы.
• HTTP/1.1 представляет концепцию конвейерной обработки (Pipelining), которая позволяет отправлять несколько запросов до того, как будет получен первый ответ. Это помогает оптимизировать использование доступной пропускной способности сети.

HTTP/1.0: не поддерживает конвейерную обработку, что делает ее менее эффективной в ситуациях, когда клиенту необходимо выполнить несколько запросов к серверу.

• HTTP/1.1: предоставляет механизмы для более эффективного использования полосы пропускания (Bandwidth), такие как фрагментированное кодирование передачи и улучшенное управление кэшем. Эти функции помогают отправлять только необходимые данные, сокращая передачу данных там, где это возможно.

HTTP/1.0: отсутствуют некоторые из этих сложных методов управления полосой пропускания.

• HTTP/1.1: улучшены механизмы обработки ошибок, предоставляющие более конкретные коды состояния для лучшего указания характера ошибки.

HTTP/1.0: Имеет более общие и менее описательные ответы об ошибках.

• HTTP/2 - дальнейшее улучшение по сравнению с HTTP/1.1 за счет введения таких функций, как мультиплексирование (несколько запросов и ответов могут смешиваться в одном соединении), передача на сервер и сжатие заголовков. Это приводит к еще большей производительности и эффективности, особенно в современных веб-приложениях, требующих высокого уровня взаимодействия и загрузки ресурсов.

Судя по всему, этот запрос представляет собой ручную операцию POST, потенциально связанную с отправкой формы или действием в панели управления доменом, которое привело к ошибке, о чем свидетельствует ответ 404. Хотя API также могут имитировать такого рода действия, комбинация заголовка реферера, метода POST и строки пользовательского агента больше указывает на ручное взаимодействие с веб-браузером вошедшего в систему пользователя, а не на автоматизированный API. вызов.

remote_addr vs http_x_forwarder_for

remote_addr - может быть реальным IP клиента или прокси. Если повторяется с http_x_forwarder_for - значит, что запрос не перенаправлялся через прокси, а шел напрямую.

http_x_forwarder_for - the original client IP.

source_host vs server_name (sn)

source_host - более общее поле, заполняемое механизмом логирования, указывающее источник события лога или имя хоста, где лог был создан. server_name (sn) - специально привязано к server_name в конфигурации NGINX, помогая определить, какой блок виртуального сервера обработал запрос.

Блок сервера определяется с помощью синтаксиса server { ... } в файле конфигурации NGINX, который обычно находится в /etc/nginx/nginx.conf или /etc/nginx/sites-enabled/. Каждый блок сервера может обрабатывать различные доменные имена, порты или конфигурации.

server {
    listen 80;  # Listen on port 80 for HTTP
    server_name example.com www.example.com;  # Respond to these domain names

    location / {
        root /var/www/html;  # Serve files from this directory
        index index.html;
    }
}