Connection reset и EOF в VLESS: что означают ошибки соединения

Ошибки вроде:

connection reset by peer

EOF

unexpected EOF

или:

io: read/write on closed pipe

регулярно встречаются в логах Xray.

Но сами по себе эти сообщения ещё не являются диагнозом.

Например, пользователь закрыл вкладку браузера, приложение отменило запрос, мобильный интернет переключился с Wi-Fi на LTE — и на одной из сторон соединения вполне может появиться запись о завершении потока.

Совсем другой случай:

каждый раз при подключении VLESS соединение падает с connection reset by peer.

Или:

большие загрузки постоянно заканчиваются unexpected EOF.

Тогда ошибка действительно помогает найти проблемный участок.

Главное — понимать, на каком уровне она появилась и кто с кем в этот момент разговаривал.

Короткий ответ

Connection reset VLESS обычно означает:

существующее TCP соединение было аварийно сброшено одной из сторон или сетевым компонентом между ними.

EOF означает:

читающая сторона больше не получила данных — поток закончился.

unexpected EOF означает:

поток закончился раньше, чем приложение ожидало.

А:

read/write on closed pipe

часто является уже следствием предыдущего закрытия соединения.

Поэтому правильный порядок диагностики:

1. Посмотреть полный текст ошибки.
2. Определить, где она записана — клиент или сервер.
3. Сравнить другой VLESS сервер.
4. Сравнить другую сеть.
5. Посмотреть access/error log Xray.
6. Если есть Nginx/CDN — проверить его отдельно.
7. Искать первую ошибку в цепочке, а не последнюю строку closed pipe.

Что такое connection reset by peer

TCP соединение обычно закрывается корректно через процедуру завершения соединения.

Но TCP также имеет флаг:

RST

то есть Reset.

RFC 9293 определяет RST как команду сбросить соединение. Если корректный RST приходит для уже установленного TCP соединения, соединение прерывается, а приложение получает уведомление о reset.

В Linux и Go это часто отображается как:

read: connection reset by peer

или:

write: connection reset by peer

Reset отличается от обычного закрытия

Упрощённо нормальное завершение выглядит так:

Client
↓ FIN
Server
↓ ACK / FIN
Client
↓ ACK

Это штатное закрытие TCP соединения.

Reset:

Client
⇄ data
Server
↓ RST
Client
→ connection reset

RST означает более резкое завершение.

RFC 9293 прямо разделяет:

• нормальный close с FIN;
• abort с RST.

«By peer» не обязательно означает «VLESS сервер»

Это одна из наиболее частых ошибок при чтении логов.

Представим:

HAPP
↓
CDN
↓
Nginx
↓
Xray

Здесь существует несколько отдельных сетевых соединений.

Например:

HAPP ⇄ CDN

и:

CDN ⇄ Nginx

и:

Nginx ⇄ Xray

Если Xray пишет:

connection reset by peer

peer для него может быть:

Nginx.

А вовсе не телефон пользователя.

То же самое с reverse proxy

Например:

Client
↓ HTTPS
Nginx
↓ HTTP/2
Xray

Если Nginx закрыл upstream connection, Xray может увидеть reset или EOF.

Клиент при этом увидит уже совсем другую ошибку:

• Network Error;
• 502;
• timeout;
• EOF.

Поэтому одна строка на одной стороне не всегда описывает полную историю.

Что такое EOF

EOF означает:

End Of File.

Но в сетевом коде никакого файла может вообще не быть.

Это просто универсальный термин:

больше данных из этого потока прочитать нельзя.

Go определяет io.EOF как значение, которое Read возвращает, когда больше входных данных нет. Причём обычный EOF используется именно для штатного окончания входного потока.

Поэтому EOF не всегда ошибка

Например:

1. Пользователь открыл сайт.
2. Получил данные.
3. Соединение нормально завершилось.
4. Читающая сторона дошла до конца потока.

EOF здесь совершенно естественен.

Именно поэтому нельзя искать по логам:

grep EOF

и считать количество строк количеством аварий.

Что такое unexpected EOF

Вот это уже другая ситуация.

Go определяет ErrUnexpectedEOF как случай, когда EOF встретился в середине чтения фиксированного блока или структуры данных.

Упрощённо программа ожидала:

[ header ][ payload 1000 bytes ]

получила:

[ header ][ 430 bytes ]

и поток внезапно закончился.

Результат:

unexpected EOF

В контексте VLESS это может выглядеть так

Xray ожидает продолжение:

• VLESS запроса;
• HTTP stream;
• mux metadata;
• transport frame;

а соединение закрывается раньше.

Например, в публичных Xray логах встречается:

proxy/vless/encoding:
failed to read request version
>
unexpected EOF

В одном из XHTTP случаев причиной оказалась неправильная reverse proxy конфигурация между клиентом и Xray.

То есть unexpected EOF сообщил:

данные оборвались не там, где ожидал Xray.

Но сам по себе он ещё не ответил:

почему.

Почему EOF — не самостоятельный диагноз

Причины могут быть совершенно разными:

• клиент закрыл connection;
• сервер закрыл connection;
• Nginx закрыл upstream;
• CDN закончил stream;
• сеть оборвалась;
• процесс перезапустился;
• transport настроен неправильно;
• mux получил повреждённый/неполный поток.

Поэтому вопрос:

как исправить EOF?

слишком общий.

Нужно выяснить:

какое соединение оборвалось до этого EOF.

Что означает closed pipe

Ещё одна характерная строка:

io: read/write on closed pipe

Go определяет ErrClosedPipe как ошибку попытки чтения или записи в уже закрытый pipe.

Очень часто это вторичная ошибка.

Например:

connection reset
↓
stream закрыт
↓
другая goroutine ещё пытается записать
↓
read/write on closed pipe

В таком случае чинить нужно не closed pipe.

Нужно искать:

почему поток закрылся раньше.

Как читать цепочку Xray

Допустим:

common/mux: unexpected EOF
>
common/mux: failed to read metadata
>
read tcp ...:
connection reset by peer

Самая полезная часть обычно находится в конце цепочки:

connection reset by peer

Она объясняет, почему mux внезапно получил EOF.

То есть:

TCP reset
↓
mux больше не получает данные
↓
unexpected EOF

В публичных Xray issues встречаются именно такие цепочки.

Не читайте только последнюю строку визуально

Xray часто строит ошибку как цепочку:

A > B > C > D

Где:

• A — верхнеуровневая операция;
• D — низкоуровневая причина.

Например:

failed to process outbound traffic
>
failed to find available destination
>
RoundTrip err
>
timeout: no recent network activity

Тогда ключ к проблеме находится в самом конце.

Connection reset сразу после подключения

Сценарий:

Connect
↓
1–3 секунды
↓
connection reset

чаще заставляет проверять:

• transport;
• reverse proxy;
• TLS/REALITY;
• server config;
• старую конфигурацию;
• неправильный endpoint.

Это отличается от соединения, которое сначала нормально работает десять минут.

Если один VLESS сервер reset, а другой работает

Например:

NL → connection reset
FR → работает
TR → работает

не нужно первым делом:

• переустанавливать HAPP;
• менять Windows;
• отключать IPv6.

Проверяйте конкретный NL endpoint.

Что может быть неисправно на одном сервере

Например:

• Xray;
• firewall;
• reverse proxy;
• CDN path;
• transport;
• routing до клиента.

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

Если все VLESS серверы reset

Тогда общая часть становится более подозрительной:

• текущая сеть;
• HAPP;
• firewall;
• другой VPN;
• клиентская версия.

Очень полезный следующий тест:

Wi-Fi ↔ LTE

Wi-Fi reset, LTE работает

Это сильный признак:

конфигурация VLESS в целом рабочая.

Меняется только путь между клиентом и сервером.

Проверяйте:

• домашнего ISP;
• роутер;
• firewall;
• маршрут.

LTE reset, Wi-Fi работает

Аналогично.

Проверяйте:

• мобильного оператора;
• 4G/5G;
• другой node;
• IPv4/IPv6.

Не нужно менять UUID рабочего VLESS профиля.

Connection reset через несколько минут

Тут уже набор причин другой.

Например:

• idle timeout;
• reverse proxy timeout;
• NAT;
• потеря сети;
• смена Wi-Fi/LTE.

Очень полезна одна деталь:

происходит ли reset примерно через одинаковый промежуток времени?

Ошибка примерно через 60 секунд

Если используется Nginx, число 60 секунд особенно интересно.

В стандартной proxy конфигурации Nginx proxy_read_timeout по умолчанию равен 60 секундам между последовательными операциями чтения. Если upstream за это время ничего не передаёт, соединение закрывается.

Для WebSocket документация Nginx также прямо отмечает, что по умолчанию proxied connection закрывается, если upstream ничего не передавал 60 секунд; время регулируется proxy_read_timeout.

Поэтому очень стабильный сценарий:

≈60 секунд
↓
disconnect

при наличии Nginx стоит расследовать отдельно.

Но не ставьте proxy_read_timeout на неделю сразу

Сначала подтвердите причину.

Если reset происходит:

• случайно;
• через 3 секунды;
• через 17 минут;

стандартный Nginx timeout может вообще не иметь отношения.

Не нужно менять параметры reverse proxy только потому, что в логе есть EOF.

WebSocket и Nginx

Для WebSocket Nginx должен корректно передавать Upgrade/Connection.

Официальная документация показывает отдельную WebSocket proxy конфигурацию и указывает необходимость проксирования Upgrade.

Если reverse proxy настроен неправильно:

• handshake может не пройти;
• connection может закрываться;
• Xray может видеть EOF/reset.

XHTTP тоже может получать unexpected EOF из-за proxy

XHTTP имеет несколько режимов:

• packet-up;
• stream-up;
• stream-one.

Reverse proxy должен корректно пропускать соответствующий HTTP stream.

В официальных Xray обсуждениях есть реальные случаи, где unexpected EOF при XHTTP оказался следствием неправильной конфигурации Caddy/reverse proxy. После исправления проксирования соединение заработало.

Поэтому:

XHTTP + unexpected EOF

не означает автоматически:

ошибка самого XHTTP.

Reverse proxy buffering тоже может вмешиваться

HTTP middleware иногда буферизует request/response.

Для streaming transport это способно дать:

• задержки;
• timeout;
• обрыв соединения.

В Xray issue описывался сценарий, где buffering reverse proxy приводил к зависанию небольших XHTTP запросов, а затем unexpected EOF на клиенте.

Это уже server-side проблема.

Обычному пользователю HAPP исправлять её нечем.

Как понять, что проблема в reverse proxy

Очень полезный тест:

Client
↓
reverse proxy
↓
Xray

не работает.

Но временный direct endpoint:

Client
↓
Xray

работает.

Тогда VLESS core и пользовательская конфигурация становятся значительно менее подозрительными.

А если Xray работает напрямую, но через CDN reset

Проверяйте:

• CDN;
• HTTP version;
• transport mode;
• timeout;
• buffering;
• origin connection.

Это уже практически доказательство, что проблема находится между CDN и origin либо в их взаимодействии.

Connection reset может приходить от destination

Есть ещё один важный случай.

Представим:

User
↓
VLESS
↓
Xray server
↓
example.com

VLESS tunnel работает прекрасно.

Но:

example.com

сбрасывает TCP connection.

Тогда Xray server может записать reset, хотя сам VPN endpoint полностью исправен.

Как отличить destination reset

Если:

Google → работает
YouTube → работает
один конкретный сайт → reset

не надо чинить VLESS inbound.

Проверяйте:

• destination;
• его firewall;
• IP reputation;
• server outbound route.

Если reset происходит на всех сайтах

Тогда уже интереснее:

• transport;
• VLESS path;
• общий server outbound;
• client network.

Контекст всегда важнее самой строки ошибки.

EOF при закрытии браузера

Представим:

1. Пользователь начал загрузку.
2. Закрыл вкладку.
3. Browser закрыл socket.
4. Proxy обнаружил EOF.

Это нормальный жизненный цикл.

Никакой администраторской работы не требуется.

Поэтому единичные EOF в error log возможны на рабочем сервере

На загруженном proxy постоянно:

• клиенты теряют сеть;
• закрывают программы;
• ноутбуки засыпают;
• телефоны переходят Wi-Fi → LTE.

Лог не обязан быть абсолютно стерильным.

Критерий проблемы:

ошибка коррелирует с реальным пользовательским сбоем.

Что действительно должно насторожить

Например:

• сотни одинаковых reset подряд;
• все пользователи одного inbound жалуются;
• конкретный transport перестал работать;
• ошибки начались после обновления;
• connection всегда падает через одинаковое время;
• один node резко перестал обслуживать traffic.

Вот это уже повод разбираться.

Как включить нормальные логи Xray

Xray имеет два основных журнала:

• access;
• error.

Также поддерживаются уровни:

• debug;
• info;
• warning;
• error;
• none.

Например:

{
  "log": {
    "access": "/var/log/xray/access.log",
    "error": "/var/log/xray/error.log",
    "loglevel": "warning"
  }
}

Для диагностики можно временно использовать info или debug

Например:

"loglevel": "info"

или:

"loglevel": "debug"

debug включает больше диагностической информации, чем info.

Но оставлять подробный debug постоянно на большом сервере обычно не требуется.

Xray умеет маскировать IP в логах

Это полезно, если лог нужно показать третьему лицу.

Актуальный Xray поддерживает:

"maskAddress": "half"

и другие уровни маскирования адресов.

Так можно уменьшить количество пользовательских IP в публикуемом диагностическом фрагменте.

Что смотреть администратору

Если Xray запущен через systemd:

journalctl -u xray --since "10 minutes ago"

или:

journalctl -u xray -f

Имя сервиса может отличаться.

В 3x-ui логика установки и размещения логов тоже зависит от конфигурации панели.

Лучше смотреть лог одновременно с воспроизведением

Например:

1. Открыли server log.
2. Нажали Connect на клиенте.
3. Воспроизвели проблемный сайт.
4. Посмотрели, что произошло именно в эту секунду.

Это намного полезнее:

grep reset огромный.log

за неделю.

Access log тоже важен

Он отвечает на вопрос:

запрос вообще дошёл до Xray?

Если пользователь нажимает Connect, но server access/error log полностью молчит:

проблема может находиться ещё до Xray.

Например:

• DNS;
• IP;
• port;
• firewall;
• CDN.

Если Xray видит запрос и потом reset

Тогда мы уже продвинулись дальше.

Например:

accepted tcp:example.com:443

а затем:

connection reset by peer

Теперь нужно понимать, какой именно connection reset:

• client ↔ Xray;
• Xray ↔ destination;
• mux stream;
• reverse proxy upstream.

Именно поэтому нужен полный log context

Одна строка:

connection reset by peer

без строк до неё мало полезна.

Лучше захватывать:

10–30 строк до ошибки и после.

По connection/session ID можно понять цепочку значительно лучше.

Не выкладывайте весь лог публично без проверки

Там могут быть:

• IP пользователей;
• домены;
• email/tag пользователей;
• внутренние адреса.

Если отправляете фрагмент на форум:

• замаскируйте адреса;
• уберите credentials;
• не публикуйте полный VLESS ключ.

tcpdump помогает определить, был ли настоящий RST

Если нужно идти глубже, можно посмотреть TCP traffic.

Например:

tcpdump -ni any 'tcp port 443'

Или для конкретного клиента:

tcpdump -ni any 'host CLIENT_IP and tcp port 443'

Если в capture реально виден:

Flags [R]

или:

[R.]

это TCP RST.

tcpdump отвечает на важный вопрос

Кто отправил reset на данном сетевом участке?

Если сервер получил RST от адреса reverse proxy, мы уже знаем:

Xray сам соединение не сбрасывал первым.

Если RST ушёл от сервера наружу:

нужно исследовать server-side stack.

Но при CDN вы не увидите реального клиента

Если:

Client
↓
Cloud/CDN
↓
Xray

server tcpdump видит соединение:

CDN ↔ Xray

Поэтому reset от CDN не доказывает:

reset отправил телефон.

Снова нужно учитывать архитектуру.

nc проверяет только порт

Например:

nc -vz example.com 443

и результат:

Connected

доказывает:

TCP handshake до порта прошёл.

Он не доказывает:

• VLESS;
• XHTTP;
• TLS;
• UUID;
• routing.

Поэтому «443 открыт» ещё не означает «VLESS работает»

Соединение может пройти:

SYN
SYN-ACK
ACK

а через секунду получить RST.

Это как раз типичный случай, когда nc показывает success, а HAPP не подключается.

curl тоже нужно интерпретировать правильно

Если VLESS endpoint сам является обычным HTTPS endpoint/reverse proxy, curl может помочь проверить HTTP/TLS.

Но прямой VLESS порт не обязан отдавать нормальную web-страницу.

Поэтому:

curl показал Empty reply

не всегда означает неисправность.

Тест должен соответствовать архитектуре сервера.

Connection reset после обновления Xray

Если проблема появилась буквально сразу после обновления:

1. Посмотрите release notes.
2. Сравните client/server versions.
3. Проверьте конфигурацию.
4. Посмотрите GitHub issues по точной ошибке.

Не нужно автоматически откатывать обновление, но временный A/B тест версии может быть полезен.

Одинаковые версии клиента и сервера не обязательны

Xray не требует всегда иметь абсолютно один номер версии с обеих сторон.

Но при использовании новых функций вроде:

• нового XHTTP поведения;
• новых параметров;

слишком старый client/server способен дать несовместимость.

Поэтому версия — один из тестов, а не универсальная причина.

Mux тоже может появляться в ошибке

Например:

common/mux: unexpected EOF

Это означает, что ошибка появилась внутри multiplexing path.

Но снова:

unexpected EOF может быть следствием того, что нижележащее TCP соединение уже reset.

В Xray issues встречаются именно цепочки:

common/mux: unexpected EOF
...
connection reset by peer

Не включайте старый mux просто ради исправления EOF

Особенно с современным XHTTP.

XHTTP имеет собственную multiplexing архитектуру XMUX.

Случайное включение дополнительного legacy mux способно только добавить ещё один слой диагностики.

Если provider profile работает без ручных mux изменений — оставьте его таким.

Один unexpected EOF после закрытия mux не обязательно проблема

Если клиент:

• отключил VPN;
• сменил server;
• приложение завершилось;

мультиплексированный transport тоже должен закончиться.

Лог вполне может содержать сообщение о завершении нескольких внутренних streams.

Ищите пользовательский симптом.

Когда EOF действительно важен

Например:

каждая загрузка 500 МБ
↓
примерно на 80–100 МБ
↓
unexpected EOF

Это уже хорошо воспроизводимый failure.

Проверяйте:

• reverse proxy;
• timeout;
• server resource;
• route.

Если мелкие сайты работают, большие загрузки обрываются

Это интересный паттерн.

Проблема может относиться к:

• long-lived connection;
• timeout;
• MTU;
• packet loss;
• reverse proxy;
• CDN.

Она меньше похожа на неправильный UUID, потому что VLESS authentication уже успешно прошла.

Если всё падает сразу после Connect

Наоборот, больше внимания:

• endpoint;
• transport;
• security;
• reverse proxy route.

Контекст времени очень полезен.

Простая классификация по времени

Как проверить пользователю HAPP

Без server access можно сделать очень много.

Тест 1. Другой сервер

Если заработал — проблема локализована.

Тест 2. Другая сеть

Wi-Fi/LTE.

Тест 3. Другой client/device

Если нужно отделить HAPP от server-side проблемы.

Тест 4. Refresh subscription

Особенно если сервер недавно обновлялся.

Не меняйте VLESS параметры случайно

Ошибка:

connection reset by peer

не говорит:

неправильный fingerprint.

Она просто говорит:

TCP connection был reset.

Чтобы сделать вывод про:

• SNI;
• UUID;
• flow;
• transport;

нужен дополнительный контекст.

Почему перебор настроек мешает

Было:

одна неизвестная проблема

Пользователь поменял:

• SNI;
• flow;
• transport;
• fingerprint.

Стало:

четыре потенциально неправильных параметра.

Диагностика только ухудшилась.

Лучше всегда возвращаться к исходной subscription.

Refresh subscription — хороший первый шаг

Если оператор изменил сервер:

• endpoint;
• transport;
• security;

старый локальный профиль может подключаться неправильно.

Refresh возвращает конфигурацию в актуальное provider state.

Что делать администратору своего сервера

Порядок я бы строил так:

1. Воспроизвести ошибку.
2. Посмотреть Xray log.
3. Проверить reverse proxy log.
4. Сравнить direct и proxied path.
5. Посмотреть tcpdump.
6. Проверить timeout.
7. Только потом менять transport/config.

Проверка Nginx

Посмотрите:

tail -f /var/log/nginx/error.log

и access log.

Если одновременно с Xray EOF появляется:

upstream prematurely closed connection

или timeout, направление поиска практически найдено.

Проверка процесса Xray

Например:

systemctl status xray

и:

journalctl -u xray --since "30 minutes ago"

Нужно убедиться, что сам процесс:

• не перезапускается;
• не падает;
• не получает OOM.

Если Xray перезапустился

Все активные connections естественно оборвутся.

Клиенты могут увидеть:

• EOF;
• reset;
• Network Error.

Тогда нет смысла анализировать каждую такую строку отдельно.

Причина:

restart процесса.

Проверьте OOM

Если серверу не хватает RAM, Linux может завершить процесс.

Полезно:

journalctl -k | grep -i -E 'oom|killed process'

Если там Xray или reverse proxy:

проблема найдена гораздо выше уровня VLESS protocol.

Проверка порта

ss -lntp

поможет увидеть:

• слушает ли нужный процесс;
• на каком address family;
• какой port.

Если reverse proxy ожидает backend на:

127.0.0.1:12345

а Xray больше там не слушает, клиентские ошибки будут лишь следствием.

Как понять, кто закрыл соединение первым

Лучший способ:

packet capture + логи обеих сторон.

Если этого нет, часто помогает временная корреляция.

Например:

12:01:04 Nginx timeout
12:01:04 Xray unexpected EOF
12:01:04 client Network Error

Вероятная цепочка уже понятна.

Connection reset не всегда требует исправления

Допустим сервер обслужил 100 000 connections.

В error/info log есть:

17 connection reset by peer

а жалоб пользователей нет.

Это совершенно другой случай, чем:

каждый второй connection reset.

Смотрите на частоту и последствия.

Почему интернет полон scary EOF логов

Потому что proxy занимается большим количеством короткоживущих соединений.

А реальные сети неидеальны.

Пользователи:

• закрывают браузеры;
• теряют Wi-Fi;
• убивают приложения.

Лог сетевого daemon по определению содержит события закрытия соединений.

Что написать поддержке VPN

Вместо:

EOF.

Лучше:

HAPP на Windows. Сервер NL подключается, но через 20–30 секунд любые загрузки обрываются. FR из той же подписки работает. Ошибка воспроизводится по Ethernet и Wi-Fi.

Это сразу исключает множество причин.

Если есть лог

Можно добавить:

connection reset by peer

с несколькими соседними строками.

Но не отправляйте только одну фразу без контекста.

Хорошее сообщение администратору

Например:

XHTTP через Nginx. Direct connection к Xray работает. Через Nginx примерно через 60 секунд stream обрывается. В Nginx и Xray логах событие происходит одновременно.

Тут уже есть конкретная гипотеза:

reverse proxy timeout/configuration.

Не публикуйте полный VLESS доступ

Для диагностики reset обычно не нужны:

• UUID;
• subscription token;
• полный QR.

Скрывайте credentials.

Таблица значений ошибок

Эти значения — отправная точка, а не готовый диагноз.

Таблица практической диагностики

Самая короткая последовательность

Если Connection reset VLESS регулярно ломает соединение:

1. Не паниковать из-за одной строки.
2. Воспроизвести проблему.
3. Попробовать другой VLESS сервер.
4. Попробовать другую сеть.
5. Посмотреть полный Xray log.
6. Найти первичную ошибку.
7. Проверить reverse proxy/CDN.
8. Сопоставить время ошибок.
9. При необходимости посмотреть TCP RST через tcpdump.

После этого уже имеет смысл менять server config.

Что НЕ стоит делать

Не нужно сразу:

• менять UUID;
• менять flow;
• менять SNI;
• менять fingerprint;
• переключать XHTTP на WebSocket;
• выключать IPv6;
• переустанавливать ОС.

Ни EOF, ни connection reset сами по себе не доказывают необходимость любого из этих действий.

Если используется готовый VLESS

Пользователю готовой subscription обычно достаточно:

другой node
↓
Refresh
↓
другая сеть

Если ошибка остаётся на одном конкретном сервере, server-side диагностика уже задача оператора.

На VLESS.ART подписка содержит несколько серверных локаций, поэтому при проблеме конкретного маршрута можно временно выбрать другой node вместо ручного изменения transport.

Посмотреть тарифы:
https://vless.art/#tarif

Итог

Ошибки Connection reset VLESS, EOF и unexpected EOF нельзя интерпретировать одинаково.

EOF в сетевом коде означает окончание входного потока и вполне может быть штатным событием. Go прямо определяет EOF как сигнал, что больше входных данных нет.

unexpected EOF означает уже другой случай:

поток закончился во время чтения данных, которые программа ожидала получить полностью.

А:

connection reset by peer

связан с TCP Reset.

RFC 9293 определяет RST как механизм аварийного прекращения TCP connection в отличие от нормального close через FIN.

Но наиболее важный нюанс:

peer — это противоположная сторона конкретного TCP соединения, а не обязательно конечный VLESS клиент или VLESS сервер.

При схеме:

HAPP
↓
CDN
↓
Nginx
↓
Xray

существует несколько отдельных connections.

Поэтому reset между Nginx и Xray может превратиться в совсем другую ошибку на телефоне.

Практическая диагностика должна идти не от слова EOF, а от поведения:

ошибка единичная или постоянная?

один сервер или все?

Wi-Fi или LTE?

direct path или reverse proxy?

соединение падает сразу или через стабильные 60 секунд?

один destination или весь интернет?

И только после этого нужно разбирать конкретный server config.

Для администратора самый полезный подход:

Xray log + reverse proxy log + точное время воспроизведения + при необходимости tcpdump.

Для обычного пользователя:

другой сервер → другая сеть → Refresh subscription → поддержка.

И если рядом с unexpected EOF есть более конкретная низкоуровневая причина вроде:

connection reset by peer

или:

timeout

начинать диагностику почти всегда стоит именно с неё, а не пытаться «исправить EOF» как отдельную ошибку.