Кратко — это не «вина» конкретно SSH/VS Code, а характер поведения UDP‑транспорта Reality / конфигурации VLESS в каскаде: при параллельных потоках проявляются проблемы с фрагментацией, мультиплексированием/лимитами соединений, NAT/conntrack или нагрузкой на шифрование, и в результате TCP‑соединения (SSH) рвутся. Ниже список возможных причин и конкретных проверок/решений.
Возможные причины
- MTU / фрагментация UDP/TCP-пакетов. Reality работает по UDP и большие пакеты могут фрагментироваться/теряться → разрывы TCP.
- Включённое мультиплексирование (mux) в VLESS/V2Ray/Xray: при ошибках mux может «ломать» вторую/следующие сессии.
- Ограничения conntrack / firewall / rate‑limit на VPS/провайдере (nf_conntrack_max, iptables connlimit), или анти‑DDoS/ограничение числа потоков/сессий.
- Перегрузка CPU/IO на промежуточных VPS (шифрование Reality/handshake может быть затратным).
- NAT/UDP timeout: при использовании UDP hole‑punching вторичные потоки могут не восстанавливаться корректно.
- Пакетная потеря / нестабильность канала между узлами (реализация Reality чувствительна к потере).
- Неправильные параметры сокета (reusePort, ulimits) или лимиты число файлов/сокетов.
- Специфические баги/особенности 3X‑UI/реализации Reality — могут вести себя иначе, чем прямой WireGuard.
Что проверить (диагностика)
1. Логи:
- Логи xray/v2ray/3X‑UI на клиенте и каждом сервере — ищите ошибки типа «read/write», «stream closed», «handshake failed», «connection reset».
- Логи SSH/sshd и логи VS Code Remote‑SSH (Output → Remote‑SSH).
2. Нагрузка:
- top/htop, iotop, vmstat на VPS при одновременных сессиях.
3. Сеть:
- mtr/traceroute/iperf3 между узлами на предмет потерь/латентности.
- tcpdump/suricata на интерфейсе сервера и клиента при воспроизведении (см. потерянные/повторные пакеты, ICMP fragmentation needed).
4. Conntrack / firewall:
- cat /proc/sys/net/netfilter/nf_conntrack_count и nf_conntrack_max
- sudo ss -s, sudo ss -tanp, sudo ss -uap
- iptables -L -n -v и правила mangle/conntrack
5. Проверка MTU/фрагментации:
- ip link show tunX/eth0; ping -M do -s <size> через туннель, посмотреть падение.
6. Тесты воспроизведения:
- Попробовать запустить несколько параллельных простых TCP‑сессий (например, nc) через туннель, чтобы понять, воспроизводится ли вне SSH/VS Code.
- Пробовать тот же сценарий через VLESS+ws/tcp вместо Reality, и через WireGuard (контрольный тест).
Конкретные действия/решения
1. Отключить mux:
- Если в конфиге VLESS/V2Ray включён mux, временно выключите его (mux: { enabled: false }) — часто помогает при проблемах с несколькими параллельными TCP‑соединениями.
2. Понизить MTU / поддержать MSS‑clamping:
- Установите MTU на туннеле клиента/сервере 1400 или 1280 и проверьте. Пример: ip link set dev wg0 mtu 1400 или для TUN интерфейса.
- На роутере/сервере: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
3. Увеличить conntrack / проверить лимиты:
- sysctl net.netfilter.nf_conntrack_max (увеличить при необходимости)
- Проверять счётчик /proc/net/nf_conntrack на drops.
4. Включить SSH‑keepalive в клиенте (VS Code использует OpenSSH конфиг):
- В ~/.ssh/config добавить:
Host *
ServerAliveInterval 60
ServerAliveCountMax 5
Это не решит корень проблемы, но уменьшит разрывы из‑за idle timeouts.
5. Тестировать альтернативные транспорты:
- Временная замена Reality на ws/tcp/h2 в VLESS — если через них проблема исчезает, значит виноват UDP‑путь/реализация Reality.
6. Проверить/увеличить системные лимиты:
- ulimit -n, systemd сервисы (LimitNOFILE) для xray/3X‑UI.
7. Мониторинг и логирование при воспроизведении:
- Смотреть tcpdump при появлении разрыва: видна ли волна RST/ICMP/массовая потеря пакетов.
8. Попробовать «скейлинг» CPU/шифрование:
- Если CPU на VPS высокий — перейти на более мощный VPS или оптимизировать/ограничить количество одновременно поддерживаемых потоков.
9. Если используете провайдера VPN/кластеры — проверить, не стоит ли там правило на ограничение числа параллельных исходящих соединений для одного клиента.
Резюме / практический план
1. Сначала включите логирование xray и ssh, воспроизведите проблему, соберите tcpdump (клиент и сервер).
2. Временно выключите mux в конфиге VLESS и проверьте повторяемость.
3. Понизьте MTU на туннелях и включите TCPMSS‑clamp.
4. Проверьте conntrack/iptables и CPU/нагрузку.
5. Если всё ещё плохо — попробуйте VLESS+ws/tcp вместо Reality; если это помогает — проблема в UDP/Reality/нейминге/провайдере.
Если хотите, могу помочь проанализировать конкретные логи и дамп трафика — пришлите вырезки из логов xray/sshd и результаты tcpdump/mtr, а также конфигурации клиента и серверов (VLESS/Reality параметры и настройки 3X‑UI).