Что именно представляет собой «Туннель», который Nginx устанавливает для подключения к внутреннему серверу при использовании WebSockets?

Я новичок в мире веб-разработки, и в настоящее время я пытаюсь создать приложение-флягу socket.io с Nginx, выступающим в качестве внешнего сервера для обработки, среди прочего, балансировки нагрузки.

Когда клиенты подключаются к моему серверу с помощью websocket, я понимаю, что клиент поддерживает постоянное и прямое соединение с Nginx, а не с моим внутренним сервером (в настоящее время он работает на сервере приложений для разработки приложений Flask). Меня смущает то, как именно сообщения websocket затем пересылаются на мой внутренний сервер. В блоге Nginx просто говорится, что он устанавливает «туннель» между клиентом и внутренним сервером, не вдаваясь в подробности того, что это за туннель на самом деле.

Поскольку внутренний прокси-сервер не знает, что он проксируется, я предполагаю, что этот «Туннель» на самом деле является вторичным соединением WebSockets между Nginx и внутренним сервером. Что-то похожее на эту передовую диаграмма. Но это также не имеет смысла, когда вы исследуете эту конфигурацию Nginx, отвечающую за настройку прокси.

location /socket.io {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;

      proxy_pass http://<name_of_backend>;

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    }

Эта часть конфигурации отвечает за пересылку рукопожатия веб-сокета (а не за пересылку последующих сообщений, для выполнения которых Nginx, похоже, не требуется какая-либо конфигурация), и он явно пересылает сюда IP-адрес клиента. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for чтобы установить рукопожатие.

Приняв это во внимание, становится ясно, что серверная часть будет использовать этот заголовок для установки соединения с веб-сокетом с предоставленным IP-адресом (IP-адрес клиента, а не обратный IP-адрес Nginx). Это означает, что этот туннель отличается от соединения WebSockets между Nginx и серверной частью. Но это не может быть просто старый TCP, потому что, во-первых, внутренний сервер не знает, что он проксируется, и ожидает, что сообщения веб-сокета будут перенаправлены на конкретный обратный вызов Socket.io для этого сообщения. Во-вторых, внутренний сервер работает на IP-адресе обратной связи, а не на общедоступном IP-адресе, поэтому он не может установить TCP-соединение с внешним миром с IP-адресом обратной связи. Так что именно этот туннель создается между Nginx и серверной частью? При повторном поиске конфигурации Nginx, необходимой для установления соединения WebSockets с клиентом