Нужно уточнить по первой части — о каком Xray вы говорите?
- Если вы имеете в виду Atlassian Xray (плагин для Jira, тест-менеджмент) — «цепочки» обычно делаются как Test с шагами, затем вы собираете их в Test Set / Test Plan и запускаете через Test Execution. Можно создавать Test с последовательностью шагов (steps) внутри самого Test; если нужна последовательность нескольких Tests — объединяете их в Test Set / Test Plan или создаёте Test Execution с нужным порядком. Могу дать пример действий и скриншоты конфигурации, если это то, что вам нужно.
- Если вы имеете в виду xray-core / v2ray-подобный прокси — поясните, что именно под «цепочками»: последовательное пробрасывание через несколько прокси (proxy chaining), fallback/outbound-последовательность или что-то другое. Для chaining обычно делают несколько локальных/удалённых инстансов и настраивают outbound как socks/http к следующему звену, либо используют balancer / routing чтобы выбирать/перенаправлять трафик.
Перехожу ко второй части — WireGuard + outbound и MSS/MTU-проблема. По дампу видно, что клиент генерирует SYN с MSS=1120 и SYN-ACK не приходит → TCP рукопожатие не происходит. Основные причины и шаги диагностики/решения:
1) Причина (чаще всего)
- При туннелировании UDP (WireGuard) общая доступная MTU для инкапсулированного TCP уменьшается. Если на пути блокируются ICMP «fragmentation needed», то Path MTU Discovery не работает и серверы не подстраивают MSS/фрагментацию — результат — SYN уходит, а ответ либо фрагментируется и отбрасывается, либо не доходит.
2) Быстрая проверка
- На сервере/peer посмотрите tcpdump/wireshark — приходят ли SYN-пакеты туда вообще.
- На стороне назначения (188.40.167.82) тоже посмотрите, доходит ли SYN и уходит ли SYN-ACK назад. Если на удалённом хосте ничего не видят — проблема с маршрутом/NAT/WG peer.
- Попробуйте с сервера подключиться к той же цели напрямую (через публичный интерфейс) — работает ли.
3) Правильное место для MSS-clamping
- Пакеты, сгенерированные локальным процессом (Xray на сервере) проходят через OUTPUT (не FORWARD). Поэтому правило TCPMSS надо ставить и для OUTPUT, и для FORWARD.
Примеры iptables (если у вас iptables-iptables, не nftables):
iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -o wg0 -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o wg0 -j TCPMSS --clamp-mss-to-pmtu
Если clamp не срабатывает, можно установить фиксированный MSS:
iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -o wg0 -j TCPMSS --set-mss 1200
4) MTU WireGuard
- Обычно WG MTU ставят ~1420 (1500 − UDP(8) − IP(20) − WG overhead), но точное значение зависит от сети. Ставить MTU слишком маленьким (1050) теоретически должно работать, но может ломать маршрутизацию или быть переопределено. Лучше вернуть MTU ~1420 и решить проблему MSS-clamp.
- Команда для изменения mtu: ip link set dev wg0 mtu 1420
5) ICMP и PMTUD
- Убедитесь, что на пути не блокируются ICMP Type 3 Code 4 (fragmentation needed). Если они блокируются, либо включите их, либо компенсируйте TCPMSS.
6) NAT / masquerade / routing
- Если трафик идет через WG и требуется маскарадинг:
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
- Проверьте AllowedIPs в конфигурации WireGuard и маршруты — чтобы пакеты к 188.40.167.82 шли через wg0.
7) Тесты для отладки
- tcpdump на локальной машине: tcpdump -i wg0 -n tcp and host 188.40.167.82
- tcpdump на удалённом узле (если есть доступ) — видит ли он SYN
- curl --interface wg0 -v https://188.40.167.82:443 (или просто telnet IP 443) чтобы проверить TCP handshake
- ping с большим размером и флагом DF: ping -M do -s 1400 188.40.167.82 — посмотрите, возвращается ли «fragmentation needed».
8) nftables
- Для nftables нужно аналогичное правило в таблице mangle (используйте tcp option set mss), но синтаксис чуть другой; если нужно, пришлю пример.
9) Дополнительно для Xray
- Если Xray запускается как systemd-сервис, убедитесь, что он действительно использует wg0 как исходящий интерфейс (маршруты/правила iptables). Можно временно запустить тестовый curl под тем же пользователем/контекстом, чтобы контролировать трафик.
Если хотите — пришлите:
- конфигурацию wg (peer/server) (без секретов)
- вывод ip addr show wg0
- вывод ip route show
- ваш iptables -t mangle -L -v
- tcpdump capture (несколько строк) с обеих сторон
На основе этого дам конкретные правила и исправления.