Почему прокси-сервер видит HTTP/2 и CONNECT-запросы, а ваш VPN-клиент — нет: разбор стека протоколов

HTTP/2 и CONNECT — это два мира, которые часто путают. Один — про эффективность, другой — про туннелирование. Прокси их видят, потому что работают на прикладном уровне. VPN — нет, потому что его стеку плевать на ваши заголовки. Разберём, где проходит граница.

Уровни, на которых всё ломается

Модель OSI — скучно, но без неё никуда. Прокси-сервер сидит на седьмом уровне. Он разбирает ваш HTTP-поток, видит метод, URI, заголовки. VPN-клиент — это сетевой уровень, третий. Он берёт IP-пакеты целиком, заворачивает их в свой туннель и отправляет. Никакого разбора содержимого.

Отсюда следует простой вывод: прокси видит всё, что вы передаёте через него в явном виде. VPN видит только IP-адреса назначения. Всё остальное — внутри шифрованного туннеля, и для VPN-клиента это просто байты.

Как прокси обрабатывает HTTP/2

HTTP/2 — это бинарный протокол. В отличие от HTTP/1.1, где заголовки читаются глазами, здесь всё упаковано в фреймы. Прокси-сервер, поддерживающий HTTP/2, должен уметь раскладывать эти фреймы, читать HPACK-сжатые заголовки и понимать мультиплексирование.

Пример: nginx с включённым HTTP/2 выглядит так:

```nginx

server {

listen 443 ssl http2;

server_name example.com;

ssl_certificate /etc/nginx/ssl/cert.pem;

ssl_certificate_key /etc/nginx/ssl/key.pem;

location / {

proxy_pass http://backend;

proxy_http_version 1.1;

proxy_set_header Host \$host;

proxy_set_header X-Real-IP \$remote_addr;

}

}

```

Здесь nginx принимает HTTP/2 от клиента, но на бэкенд отдаёт по HTTP/1.1. Это стандартная практика: внутренняя инфраструктура редко готова к HTTP/2, а прокси выступает переводчиком.

CONNECT-метод — что это такое

CONNECT — это особый метод HTTP. Он говорит прокси: "не читай мои данные, просто открой TCP-туннель до указанного хоста". Прокси устанавливает соединение с целевым сервером и дальше просто пересылает байты в обе стороны.

Это основа HTTPS-проксирования. Браузер отправляет CONNECT example.com:443, прокси открывает соединение, и дальше клиент и сервер общаются напрямую через шифрованный TLS-туннель. Прокси не видит содержимого, но видит, куда вы идёте.

Почему VPN не видит HTTP/2

VPN-клиент работает ниже. Он создаёт виртуальный сетевой интерфейс, через который маршрутизирует трафик. Весь ваш HTTP/2, TLS, QUIC — всё это упаковывается в IP-пакеты и отправляется через туннель.

Пример: OpenVPN с tap-режимом работает на канальном уровне. Он передаёт Ethernet-кадры. Ваш HTTP/2 внутри TCP-сегмента внутри IP-пакета внутри Ethernet-кадра. OpenVPN видит только Ethernet-кадры. Ему неоткуда узнать, что там внутри.

WireGuard — ещё ниже. Он работает на сетевом уровне, передаёт IP-пакеты. Но даже он не разбирает их содержимое. Для WireGuard ваш HTTP/2 — это просто набор байтов в полезной нагрузке.

Разница в видимости трафика

Прокси видит:

- Метод запроса (GET, POST, CONNECT)

- URI и заголовки

- Тело запроса (если не используется CONNECT)

- Версию протокола (HTTP/1.1, HTTP/2)

VPN видит:

- IP-адреса источника и назначения

- Порты

- Протокол (TCP, UDP, ICMP)

- Размеры пакетов

Всё остальное — зашифровано или скрыто внутри туннеля.

Практический пример: как прокси видит HTTP/2

Возьмём curl и посмотрим, что видит прокси. Настроим простой HTTP-прокси на Python:

```python

import socket

import threading

def handle(client_sock):

data = client_sock.recv(65535)

print("Received:", data[:200])

client_sock.close()

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

server.bind(('127.0.0.1', 8080))

server.listen(5)

while True:

client, addr = server.accept()

threading.Thread(target=handle, args=(client,)).start()

```

Запускаем и отправляем HTTP/2-запрос через прокси:

```bash

curl --http2 -x http://127.0.0.1:8080 https://example.com

```

Прокси увидит:

```

Received: CONNECT example.com:443 HTTP/1.1

Host: example.com:443

User-Agent: curl/8.0.1

Proxy-Connection: Keep-Alive

```

Curl использует CONNECT для HTTPS-сайтов, даже если сам протокол — HTTP/2. Сам HTTP/2-трафик будет внутри TLS-туннеля, который прокси не видит.

Что происходит с HTTP/2 при CONNECT

Когда вы используете HTTPS-прокси, HTTP/2 идёт поверх TLS. Прокси видит только CONNECT-запрос и дальше просто пересылает зашифрованные байты. Он не может прочитать HTTP/2-заголовки, потому что они внутри TLS.

Но есть нюанс. Существует протокол HTTP/2 Extended CONNECT. Он позволяет передавать метаданные о туннеле в HTTP/2-фреймах. Это используется для проксирования WebSocket и других протоколов. Но это редкость, большинство прокси до сих пор работают с классическим CONNECT из HTTP/1.1.

Кейс: nginx и HTTP/2 CONNECT

Пример: nginx 1.24 с настроенным проксированием. Когда клиент отправляет CONNECT, nginx может обработать его двумя способами. Первый — через `proxy_connect` модуль, который открывает TCP-соединение. Второй — через `stream` модуль, который работает на четвёртом уровне.

```nginx

stream {

server {

listen 443;

proxy_pass backend_server:443;

}

}

```

Этот конфиг не разбирает HTTP вообще. Он просто принимает TCP-соединение и передаёт его дальше. Никакого HTTP/2, никаких заголовков. Просто поток байтов.

Кейс: Squid и CONNECT-запросы

Squid — классика проксирования. Он поддерживает CONNECT, но по умолчанию ограничивает порты. Вот типичный конфиг:

```squid

acl SSL_ports port 443

acl CONNECT method CONNECT

http_access allow CONNECT SSL_ports

http_access deny CONNECT

```

Squid видит CONNECT-запрос, проверяет порт назначения и либо разрешает, либо блокирует. При этом он не может заглянуть внутрь туннеля. Если внутри HTTPS — всё шифровано. Если внутри HTTP/2 — тоже шифровано, потому что HTTP/2 без TLS работает только через h2c, который редко встречается в реальном мире.

Кейс: OpenVPN и HTTP/2

OpenVPN с протоколом UDP. Вы подключаетесь к серверу, получаете виртуальный IP. Дальше ваш браузер отправляет HTTP/2-запросы через эту виртуальную сеть. OpenVPN-сервер получает IP-пакеты и передаёт их в физическую сеть.

Что видит OpenVPN-сервер? IP-пакеты с вашего виртуального адреса. Он не знает, что внутри — HTTP/2, FTP или SSH. Для него это просто IP-пакеты. Если включено сжатие или шифрование на уровне туннеля — он видит зашифрованные данные.

Почему это важно для безопасности

Прокси-сервер — это точка контроля. Он может блокировать запросы по URI, заголовкам, методу. VPN-сервер — это просто маршрутизатор. Он не может блокировать конкретные запросы, потому что не видит их.

Поэтому корпоративные политики безопасности часто используют прокси, а не VPN. Прокси может запретить доступ к конкретным URL или заблокировать определённые типы файлов. VPN может только ограничить доступ к IP-адресам или портам.

Что выбрать: прокси или VPN

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

На практике часто используют связку. Например, компания lexic.ml предоставляет IPv6-прокси, которые работают на прикладном уровне и позволяют контролировать HTTP/2-трафик. А VPN используется для полного туннелирования.

Технические детали: MTU и фрагментация

Ещё один момент, где прокси и VPN расходятся. VPN добавляет свои заголовки к каждому пакету. Это увеличивает размер пакета и может вызвать фрагментацию. Прокси работает на уровне TCP-соединений и не влияет на MTU.

Пример: ваш MTU 1500 байт. OpenVPN добавляет заголовок в 40-50 байт. Фактический размер пакета становится 1540-1550 байт. Это вызывает фрагментацию на уровне IP. Результат — падение скорости на 10-20% из-за повторной сборки пакетов.

Прокси не имеет этой проблемы. Он работает на уровне TCP, где сегментация управляется протоколом и не зависит от MTU физического интерфейса.

Итоги

Прокси и VPN — разные инструменты для разных задач. Прокси видит HTTP/2 и CONNECT, потому что работает на прикладном уровне. VPN — нет, потому что работает на сетевом уровне. Выбор зависит от того, что вам нужно: контроль трафика или его полное скрытие.

Если вам нужен прокси с поддержкой HTTP/2 и CONNECT — смотрите в сторону Squid, nginx или специализированных решений. Если нужен полный туннель — OpenVPN, WireGuard или IPSec. А если нужен IPv6-прокси с нормальной поддержкой современных протоколов — обратите внимание на lexic.ml, там это работает из коробки.