У меня проблема при подключении к моему xray серве...

Question

У меня проблема при подключении к моему xray серверу. Клиент sing-box, система linux.

Текущая настройка в система для DNS

DNS over sing box

📝 Настройка DNS через sing-box + dnsmasq

Все программы в Linux будут стучать в локальный 127.0.0.1:53
dnsmasq примет запрос → форвардит в sing-box (на нестандартный порт, например 1053)
sing-box отправит DNS-запрос через твой VLESS-прокси

Провайдер при этом увидит только TLS-трафик к серверу, но не исходные DNS-запросы.

Что мы сделали

Отключили системный резолвер
- В /etc/NetworkManager/NetworkManager.conf добавили:
```
ini
[main]
dns=none
```
- Перезапустили NetworkManager:
```
bash
sudo systemctl restart NetworkManager
```

Настроили dnsmasq как локальный DNS-stub
В /etc/dnsmasq.conf прописали:

ini
# слушаем только локальный интерфейс
listen-address=127.0.0.1

# жёстко привязывает сокет к конкретному IP/интерфейсу, указанному в listen-address. 
# Это критически важно, потому что мы хотим, чтобы dnsmasq строго слушал только 127.0.0.1, 
# а не случайно открыл DNS наружу (на enp2s0 или tun0).
bind-interfaces

# не читать /etc/resolv.conf (чтобы случайно не использовать DNS провайдера)
no-resolv

# пересылаем ВСЕ запросы в sing-box (локальный порт 1053)
server=127.0.0.1#1053

# не пересылать ненужные PTR-запросы наружу
bogus-priv

# блокируем IPv6-запросы (по желанию, если нужно)
# filter-aaaa

Перезапустили сервис:

bash
sudo systemctl enable --now dnsmasq

Указали в системе использовать только dnsmasq
В /etc/resolv.conf:
```
ini
nameserver 127.0.0.1
```
Если стоит resolvconf или systemd-resolved → закрепили этот файл через chattr:
```
bash
sudo chattr +i /etc/resolv.conf
```
Проверка
- Локальные запросы:
```
bash
dig @127.0.0.1 google.com
```
  должны уходить в 127.0.0.1#1053 (sing-box).
- На реальном интерфейсе (enp2s0) нет трафика на порт 53:
```
bash
sudo tcpdump -i enp2s0 -n port 53
```

Важно! Раньше с этой конфигурацией всё работало, но перестало без видимых причин.
Вот какие ошибки получаю.
+0300 2025-10-14 21:48:59 INFO [1820780125 0ms] inbound/direct[local-dns-in]: inbound packet connection from 127.0.0.1:41268
+0300 2025-10-14 21:48:59 INFO [1820780125 0ms] inbound/direct[local-dns-in]: inbound packet connection to 127.0.0.1:53
+0300 2025-10-14 21:48:59 DEBUG [1820780125 0ms] router: match[0] => sniff
+0300 2025-10-14 21:48:59 DEBUG [1820780125 0ms] router: sniffed packet protocol: dns
+0300 2025-10-14 21:48:59 DEBUG [1820780125 0ms] router: match[1] => resolve
+0300 2025-10-14 21:48:59 DEBUG [1820780125 0ms] router: match[2] protocol=dns || port=53 => hijack-dns
+0300 2025-10-14 21:48:59 DEBUG [1820780125 0ms] dns: exchange ping.manjaro.org. IN A
+0300 2025-10-14 21:48:59 INFO [2575630200 0ms] inbound/direct[local-dns-in]: inbound packet connection from 127.0.0.1:42907
+0300 2025-10-14 21:48:59 INFO [2575630200 0ms] inbound/direct[local-dns-in]: inbound packet connection to 127.0.0.1:53
+0300 2025-10-14 21:48:59 DEBUG [2575630200 0ms] router: match[0] => sniff
+0300 2025-10-14 21:48:59 DEBUG [2575630200 0ms] router: sniffed packet protocol: dns
+0300 2025-10-14 21:48:59 DEBUG [2575630200 0ms] router: match[1] => resolve
+0300 2025-10-14 21:48:59 DEBUG [2575630200 0ms] router: match[2] protocol=dns || port=53 => hijack-dns
+0300 2025-10-14 21:48:59 DEBUG [123803605 20.2s] dns: exchange www.youtube.com. IN A
+0300 2025-10-14 21:48:59 DEBUG [2575630200 0ms] dns: exchange www.youtube.com. IN AAAA
+0300 2025-10-14 21:49:00 DEBUG [2009591431 20.2s] dns: exchange detectportal.firefox.com. IN AAAA
+0300 2025-10-14 21:49:00 DEBUG [3850157977 20.2s] dns: exchange detectportal.firefox.com. IN A
+0300 2025-10-14 21:49:02 DEBUG [3615164628 11.2s] dns: exchange ident.me. IN AAAA
+0300 2025-10-14 21:49:02 DEBUG [1182458267 22.4s] dns: exchange ident.me. IN A
+0300 2025-10-14 21:49:04 INFO [123803605 24.53s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1182458267 24.19s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [3430647593 24.53s] dns: exchange failed for www.youtube.com. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [4026147774 24.9s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [123803605 24.53s] dns: exchange failed for www.youtube.com. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [2095817429 24.9s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1239575017 24.9s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [4026147774 24.9s] dns: exchange failed for example.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [1182458267 24.19s] dns: exchange failed for ident.me. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [2815120891 24.9s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [2095817429 24.9s] dns: exchange failed for example.org. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [2009591431 24.9s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1239575017 24.9s] dns: exchange failed for ipv4only.arpa. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [2815120891 24.9s] dns: exchange failed for ipv4only.arpa. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [2009591431 24.9s] dns: exchange failed for detectportal.firefox.com. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [3850157977 24.9s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [3850157977 24.9s] dns: exchange failed for detectportal.firefox.com. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1586948756 25.8s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1586948756 25.8s] dns: exchange failed for ident.me. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1586948756 25.8s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1553874406 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1586948756 25.8s] dns: exchange failed for ident.me. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1553874406 25.0s] dns: exchange failed for ping.manjaro.org. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1468295140 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [3615164628 13.17s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 INFO [1553874406 25.0s] outbound/vless[proxy]: outbound packet connection to 1.1.1.1:53
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [3615164628 13.17s] dns: exchange failed for ident.me. IN AAAA: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 ERROR [1468295140 25.0s] dns: exchange failed for ping.manjaro.org. IN A: dial tcp 85.192.63.245:443: i/o timeout
+0300 2025-10-14 21:49:04 DEBUG [2575630200 5.0s] dns: exchange www.youtube.com. IN AAAA
+0300 2025-10-14 21:49:04 INFO [2008844448 0ms] inbound/direct[local-dns-in]: inbound packet connection from 127.0.0.1:57708
+0300 2025-10-14 21:49:04 INFO [2008844448 0ms] inbound/direct[local-dns-in]: inbound packet connection to 127.0.0.1:53
+0300 2025-10-14 21:49:04 DEBUG [2008844448 0ms] router: match[0] => sniff
+0300 2025-10-14 21:49:04 DEBUG [2008844448 0ms] router: sniffed packet protocol: dns
+0300 2025-10-14 21:49:04 DEBUG [2008844448 0ms] router: match[1] => resolve
+0300 2025-10-14 21:49:04 DEBUG [2008844448 0ms] router: match[2] protocol=dns || port=53 => hijack-dns

Answer 1

Похоже, у тебя сломалось не «DNS через dnsmasq/sing-box», а сам выезд в интернет через прокси: sing-box не может достучаться до твоего VLESS-сервера.

Что видно из логов

Запросы приходят в inbound local-dns-in на 127.0.0.1:53:
```
text
inbound packet connection to 127.0.0.1:53
router: protocol=dns => hijack-dns
```
⇒ Сейчас sing-box слушает порт 53, а не 1053.
Дальше sing-box пытается резолвить через твой DNS-апстрим (1.1.1.1) поверх прокси, но сам прокси не поднимается:
```
text
outbound/vless[proxy]: ... to 1.1.1.1:53
dns: ... dial tcp 85.192.63.245:443: i/o timeout
```
⇒ TCP-подключение к твоему VLESS-серверу 85.192.63.245:443 из клиента не устанавливается (таймаут на соединении). Это либо:
- сервер лег/не слушает 443,
- фаервол/провайдер блокирует,
- IP поменялся/route сломан,
- порт на сервере изменили.

Из-за этого все DNS-обмены «через прокси» падают.

Быстрая диагностика (клиент)

Проверить доступность сервера

bash
# простой коннект
nc -vz 85.192.63.245 443

# трассировка до узла
mtr -rwzc 5 85.192.63.245

# попытка TCP SYN (увидишь хотя бы SYN/ACK/RST)
sudo hping3 -S -p 443 -c 3 85.192.63.245

Если везде таймаут → блок/route проблема вне sing-box.
Если «refused»/RST → порт открыт, но служба не слушает/не совпадает протокол.

Кто держит 53/1053 локально

bash
sudo ss -lunpt | egrep '(:53|:1053)\b'
systemctl status dnsmasq
systemctl status systemd-resolved

Если sing-box слушает 53, а dnsmasq тоже пытается занять 53 — будет конфликт. Либо переведи sing-box на 1053, либо в dnsmasq.conf укажи server=127.0.0.1#53. Главное — синхронизируй порт.

Проверка/исправление на сервере (если есть доступ)

bash
# Xray/ sing-box на сервере
sudo systemctl status xray
sudo journalctl -u xray -n 100 --no-pager

# порт и фаервол
sudo ss -ltnup 'sport = :443'
sudo ufw status verbose || sudo iptables -S | grep 443

Убедись, что:

слушается TCP 443 (и тот транспорт, который настроен — tcp/ws/grpc/REALITY),
UUID/flow/SNI/host/shortId/publicKey (для REALITY/Vision) не менялись,
если переносил порт — измени его и на клиенте.

Важно: твой лог — таймаут на TCP-коннекте. Это происходит до TLS/REALITY-рукопожатия. Значит, проблема с сетевой доступностью (IP/порт/фаервол/блок), а не с несовпадением ключей/shortId.

Временный «буфер» чтобы оживить резолв

Пока чинится доступ к серверу, можно временно дать DNS ходить в обход прокси (понимая риски утечки DNS к провайдеру):

Вариант A (быстро через dnsmasq):

ini
# /etc/dnsmasq.conf (временно)
no-resolv
server=1.1.1.1
# или DoT через stubby/unbound, если хочешь шифрование без прокси

Перезапусти:

bash
sudo systemctl restart dnsmasq

Вариант B (через sing-box): В dns.servers[] для одного апстрима поставь "detour": "direct", а dns.final укажи на него:

json
"dns": {
  "servers": [
    { "tag": "cf-direct", "address": "1.1.1.1", "strategy": "prefer_ipv4", "detour": "direct" },
    { "tag": "cf-proxy",  "address": "1.1.1.1", "strategy": "prefer_ipv4", "detour": "proxy" }
  ],
  "final": "cf-direct"
}

Потом вернёшь на cf-proxy, когда VLESS оживёт.

Приведи в порядок порт 53/1053 (на выбор)

Вариант 1: sing-box на 1053, dnsmasq форвардит на 1053

sing-box (фрагмент)

json
"inbounds": [
  {
    "type": "direct",
    "tag": "local-dns-in",
    "listen": "127.0.0.1",
    "listen_port": 1053,
    "sniff": true
  }
],
"route": {
  "rules": [
    { "protocol": "dns", "outbound": "hijack-dns" }
  ]
}

/etc/dnsmasq.conf

ini
listen-address=127.0.0.1
bind-interfaces
no-resolv
server=127.0.0.1#1053
bogus-priv
# filter-aaaa  # если нужно

Вариант 2: sing-box слушает 53, dnsmasq не нужен

Тогда отключи dnsmasq, освободи 53 от других демонов и укажи в /etc/resolv.conf:

nameserver 127.0.0.1

(и закрепи chattr +i, если требуется).

Чек-лист «почему внезапно перестало»

На сервере обновили Xray/sing-box и сменились ключи/shortId/flow (для REALITY/Vision) — клиент остался со старым конфигом. Но у тебя именно таймаут, так что сперва проверь доступность порта/IP.
Хостер/провайдер начал фильтровать TCP 443 к твоему IP. Попробуй порт 2053/2087/2096/8443 или другой IP.
На сервере включили/ужесточили UFW/iptables/security-group.
IP сервера изменился (если совпадал с доменом, а ты сейчас подключаешься по голому IP).
На клиенте что-то перехватило порт 53 (systemd-resolved) и мешает твоей схеме.

Мини-план действий

Прогони nc -vz 85.192.63.245 443 и mtr — пойми, доступен ли сервер с клиента.
Если недоступен → проверь фаервол/порт/маршрут/смену IP на сервере; попробуй альтернативный порт.
На время — переключи DNS на direct, чтобы не быть «слепым».
Синхронизируй, кто слушает 53/1053 (sing-box vs dnsmasq), чтобы не было конфликта.

Если хочешь, скидывай свои фрагменты конфигов sing-box (dns, inbounds, outbounds[proxy]) и вывод трёх команд:

text
nc -vz 85.192.63.245 443
sudo ss -ltnup 'sport = :443'
sudo systemctl status xray

— подскажу точечно, что именно править.

Answer 2

Спасибо за конфиг и проверки — картина сложилась.

Главное: у тебя TUN (auto_route:true, strict_route:true) + final: "proxy". Без явного «байпаса» сам сервер (85.192.63.245:443) уходит… через тот же прокси/туннель. Пока туннель не поднят, трафик до сервера зацикливается и connect() ловит таймаут — ровно то, что было в логах (dial tcp 85.192.63.245:443: i/o timeout). nc -vz сейчас успешен, потому что он шёл прямо по системному маршруту (либо в момент проверки TUN был неактивен/маршрут уже выправился). Чтобы это не «плавало», сервер надо исключить из туннеля и отправлять DIRECT всегда.

Плюс у тебя в dns.servers[] объект с полями type/server, а в sing-box используется поле address (а протокол задают префиксом udp://, tls://, https://). Это не критично для объяснения таймаутов к серверу, но лучше поправить, чтобы DNS-конфиг был корректным и предсказуемым.

Что поправить (минимальный патч)

Исключи IP сервера из TUN и рути его DIRECT

В inbounds[0].tun.route_exclude_address добавь IP:

json
"route_exclude_address": [
  "192.168.0.0/16",
  "10.0.0.0/8",
  "172.16.0.0/12",
  "85.192.63.245/32"
]

В route.rules выше правила final добавь принудительный DIRECT:

json
{ "ip_cidr": ["85.192.63.245/32"], "outbound": "direct" }

Приведи DNS-блок к валидному синтаксису
(и оставь возможность быстро переключиться на direct, если прокси снова отвалится)

json
"dns": {
  "servers": [
    {
      "tag": "dns_proxy",
      "address": "udp://9.9.9.9",
      "strategy": "prefer_ipv4",
      "detour": "proxy"
    },
    {
      "tag": "dns_direct",
      "address": "tls://1.1.1.1:853",
      "strategy": "prefer_ipv4",
      "detour": "direct"
    }
  ],
  "rules": [],
  "final": "dns_proxy"
}

Если нужно «временно оживить» резолв при падении прокси — замени final на "dns_direct" и верни назад, когда VLESS оживёт.

DNS inbound: оставь порт 1053 и убери override_port
override_port: 53 тут не нужен и только путает логи.

json
{
  "type": "direct",
  "tag": "local-dns-in",
  "listen": "127.0.0.1",
  "listen_port": 1053
}

dnsmasq по-прежнему форвардит на 127.0.0.1#1053 — всё сойдётся.

Порядок правил маршрутизации
Оставь как есть, но проверь, что правило ip_cidr 85.192.63.245/32 -> direct стоит выше логического REJECT и выше любых общих правил, чтобы точно сработало:

json
"route": {
  "rules": [
    { "action": "sniff" },
    { "protocol": "dns", "action": "hijack-dns" },
    { "inbound": "local-dns-in", "outbound": "dns_proxy" },

    { "ip_cidr": ["85.192.63.245/32"], "outbound": "direct" },

    {
      "type": "logical",
      "mode": "or",
      "rules": [
        { "port": 853 },
        { "network": "udp", "port": 443 },
        { "protocol": "stun" }
      ],
      "action": "reject",
      "method": "default"
    },

    { "ip_is_private": true, "outbound": "direct" },
    { "domain": ["vd.aq.ru"], "outbound": "direct" },
    { "domain": ["www.speedtest.net"], "outbound": "direct" },
    { "domain": ["www.lk.tltinet.ru"], "outbound": "direct" }
  ],
  "final": "proxy",
  "auto_detect_interface": true
}

Быстрая проверка после правок

bash
# 1) Валидация конфига
sing-box check -c /путь/к/config.json

# 2) Перезапуск
sudo systemctl restart sing-box

# 3) Кто слушает DNS-порты
sudo ss -lunpt | egrep '(:53|:1053)\b'
systemctl status dnsmasq

# 4) Локальный DNS через цепочку
dig @127.0.0.1 -p 53 example.org +time=2 +tries=1
dig @127.0.0.1 -p 1053 example.org +time=2 +tries=1   # если напрямую в sing-box

# 5) Нет ли утечек DNS наружу:
sudo tcpdump -i enp2s0 -n port 53

Если после этих правок ещё увидишь «dial tcp … i/o timeout», пришли 20–30 строк свежих логов sing-box (уровень debug) сразу после старта и результат:

ip route get 85.192.63.245

— проверим, что маршрут до сервера действительно идёт в обход singtun0.

Отдельно: на сервере Xray активен и слушает *:443, UFW выключен — это хорошо. Для REALITY/Vision важно, чтобы server_name на клиенте (github.com) входил в serverNames на сервере, и public_key/shortId совпадали, но при таймауте connect() до этого этапа дело не доходит — сперва нужно стабильно добираться до 85.192.63.245:443 без попыток завернуть этот трафик в туннель.

Answer 3

Отличные прогоны! Сейчас видно:

DNS-цепочка dnsmasq(53) → sing-box(1053) работает (оба dig ок).
Но у тебя есть утечки DNS наружу: tcpdump показал прямые пакеты на 8.8.8.8:53 с реального интерфейса enp2s0.
Плюс curl ident.me рвётся — это уже плоскость data-plane через VLESS/REALITY.

Ниже — компактный план, который закрывает обе проблемы и убирает предупреждения sing-box check (миграция DNS-секции).

1) Обнови конфиг sing-box (новый формат DNS + байпас до сервера)

Заменяй соответствующие куски (секреты не забудь подставить):

json
{
  "log": { "level": "debug", "timestamp": true },

  "dns": {
    "servers": [
      {
        "tag": "dns_proxy",
        "address": "https://dns.quad9.net/dns-query",
        "strategy": "prefer_ipv4",
        "detour": "proxy"
      },
      {
        "tag": "dns_direct",
        "address": "tls://1.1.1.1:853",
        "strategy": "prefer_ipv4",
        "detour": "direct"
      }
    ],
    "final": "dns_proxy"
  },

  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "singtun0",
      "address": ["172.18.0.1/30"],
      "mtu": 1500,
      "auto_route": true,
      "strict_route": true,
      "route_exclude_address": [
        "192.168.0.0/16",
        "10.0.0.0/8",
        "172.16.0.0/12",
        "85.192.63.245/32"              // ВАЖНО: твой сервер всегда в обход туннеля
      ]
    },
    {
      "type": "direct",
      "tag": "local-dns-in",
      "listen": "127.0.0.1",
      "listen_port": 1053
    }
  ],

  "outbounds": [
    { "type": "direct", "tag": "direct" },
    {
      "type": "vless",
      "tag": "proxy",
      "server": "85.192.63.245",
      "server_port": 443,
      "uuid": "YOUR-UUID",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "github.com",
        "utls": { "enabled": true, "fingerprint": "chrome" },
        "reality": { "enabled": true, "public_key": "PUBKEY", "short_id": "SHORTID" }
      }
    },
    { "type": "block", "tag": "block" }
  ],

  "route": {
    "default_domain_resolver": "dns_proxy",         // убирает предупреждение о миграции
    "auto_detect_interface": true,
    "rules": [
      { "action": "sniff" },
      { "protocol": "dns", "action": "hijack-dns" },
      { "inbound": "local-dns-in", "outbound": "dns_proxy" },

      { "ip_cidr": ["85.192.63.245/32"], "outbound": "direct" }, // БАЙПАС до сервера

      {
        "type": "logical",
        "mode": "or",
        "rules": [
          { "port": 853 },
          { "network": "udp", "port": 443 },
          { "protocol": "stun" }
        ],
        "action": "reject",
        "method": "default"
      },

      { "ip_is_private": true, "outbound": "direct" },
      { "domain": ["vd.aq.ru","www.speedtest.net","www.lk.tltinet.ru"], "outbound": "direct" }
    ],
    "final": "proxy"
  }
}

Почему это важно:

Новый формат DNS (address: с https:///tls://) — без деприкаций.

БАЙПАС 85.192.63.245/32 гарантирует, что соединение к серверу никогда не уйдёт в сам туннель.

default_domain_resolver убирает второе предупреждение check.

2) Жёстко пресечь утечки DNS на уровне хоста

Даже если какое-то приложение игнорирует resolv.conf и шлёт на 8.8.8.8, перехватим это локально.

nftables (современные системы)

bash
sudo nft add table inet dnsredir
sudo nft add chain inet dnsredir output '{ type nat hook output priority 0; }'
sudo nft add rule inet dnsredir output udp dport 53 redirect to :53
sudo nft add rule inet dnsredir output tcp dport 53 redirect to :53

iptables-nft (если удобнее iptables)

bash
sudo iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53
sudo iptables -t nat -A OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 53

Это «пояс с подтяжками»: весь локальный :53 уходит к твоему dnsmasq на 127.0.0.1:53, а тот уже форвардит в sing-box:1053.

Проверь, что в /etc/dnsmasq.conf действительно есть:

text
listen-address=127.0.0.1
bind-interfaces
no-resolv
server=127.0.0.1#1053

и нет лишних server= из /etc/NetworkManager/dnsmasq.d/*.conf:

bash
grep -R "server=" /etc/dnsmasq* /etc/NetworkManager/dnsmasq.d/ -n || true
sudo systemctl restart dnsmasq

3) Перезапуск и проверки

bash
# Валидация конфига
sing-box check -c /путь/к/конфигу.json

# Перезапуск
sudo systemctl restart sing-box

# Должно слушать ровно так:
sudo ss -lunpt | egrep '(:53|:1053)\b'
# udp 127.0.0.1:53 (dnsmasq), udp/tcp 127.0.0.1:1053 (sing-box)

# DNS через цепочку
dig @127.0.0.1 example.org +time=2 +tries=1
dig @127.0.0.1 -p 1053 example.org +time=2 +tries=1

# Отсутствие утечек:
sudo tcpdump -i enp2s0 -n port 53   # должно быть пусто при обычном резолве

4) Проверка data-plane через прокси (VLESS/REALITY)

Убедись, что маршрут к серверу действительно DIRECT:

bash
ip route get 85.192.63.245
# Ожидаем dev enp2s0 (или твой физический iface), НЕ singtun0

Тест страницы:

bash
curl -v https://ident.me/ --max-time 5

Если снова Recv failure/RST:

Это уже согласование Vision/REALITY. Проверь на сервере Xray:
- inbound flow: "xtls-rprx-vision"
- reality → private_key соответствует твоему public_key на клиенте,
- short_ids содержит твой short_id,
- server_names включает github.com (или поменяй server_name у клиента на то, что реально разрешено на сервере).

В случае именно Vision/REALITY несоответствий в логах sing-box обычно есть явные сообщения (invalid short id / reality handshake failed). Если понадобится — кинь 20–30 строк sing-box логов уровня debug вокруг попытки curl.

Почему `tcpdump` видел 8.8.8.8

Какие-то процессы (иногда браузеры/проги, Docker-контейнеры, NetworkManager-скрипты) игнорируют resolv.conf и бьют на публичные DNS. TUN всё равно должен их перехватывать, но в реальной жизни иногда «проскальзывает». Редирект на уровне хоста (п.2) убивает класс утечек гарантированно.

Если сделаешь правки и всё равно будут сбои — пришли:

вывод ip rule, ip route show table all | sed -n '1,200p' | sed -n '200,400p' (или хотя бы ip route get 85.192.63.245);
20–30 строк свежих логов sing-box уровня debug при неудачном curl.

Должно полететь. 🚀

Answer 4

Спасибо за логи — теперь видно точнее, что ломается.

Что именно падает сейчас

В каждой строке видно: outbound/vless[proxy]: outbound connection to dns.quad9.net:443, а затем dns: exchange failed … context deadline exceeded.
Это означает: DNS-апстрим внутри sing-box (DoH к Quad9 через прокси) не отвечает. Причём это уже трафик сервер → Quad9, т.е. после установления канала клиент→VLESS-сервер. Если на хостинге сервера Quad9 недоступен/фильтруется, все DNS-запросы через прокси будут «зависать».

Менять клиентский порт с 443 на 2096/8443 имеет смысл только если блокируется соединение клиент → ваш сервер. Тут же отваливается сервер → Quad9, поэтому смена порта клиента проблему DNS не решит. Сначала сделаем апстрим, который гарантированно доступен с вашего сервера.

Поправляем DNS в sing-box (без деприкаций и без «зависаний»)

Сделайте один из вариантов для dns.servers и добавьте default_domain_resolver (чтобы убрать предупреждения check). Плюс — важно — зададим резолвер адреса апстрим-хоста как direct, чтобы не было «курица-яйцо».

Вариант A (надёжный): DoT Cloudflare по IP (не требует резолва)

json
"dns": {
  "servers": [
    {
      "tag": "dns_proxy",
      "address": "tls://1.1.1.1:853",
      "strategy": "prefer_ipv4",
      "detour": "proxy"
    },
    {
      "tag": "dns_direct",
      "address": "tls://1.0.0.1:853",
      "strategy": "prefer_ipv4",
      "detour": "direct"
    }
  ],
  "final": "dns_proxy"
},
"route": {
  "default_domain_resolver": "dns_direct",
  ...
}

Плюс: не нужен DNS для самого апстрима (IP), значит исключаем циркулярную зависимость. Если хостинг режет Quad9 — Cloudflare обычно жив.

Вариант B (если хотите DoH): Cloudflare DoH с «подстраховкой»

json
"dns": {
  "servers": [
    {
      "tag": "dns_proxy",
      "address": "https://cloudflare-dns.com/dns-query",
      "address_resolver": "dns_direct",
      "strategy": "prefer_ipv4",
      "detour": "proxy"
    },
    {
      "tag": "dns_direct",
      "address": "tls://1.1.1.1:853",
      "strategy": "prefer_ipv4",
      "detour": "direct"
    }
  ],
  "final": "dns_proxy"
},
"route": {
  "default_domain_resolver": "dns_direct",
  ...
}

Здесь address_resolver: "dns_direct" гарантирует, что имя cloudflare-dns.com будет резолвиться в обход прокси, и DoH не «зависнет» из-за отсутствия DNS до него.

Оставьте ваши предыдущие «антиутечки» (dnsmasq на 53, sing-box на 1053, iptables/nft редирект 53→локально) — это правильно.

Проверьте доступность апстримов с сервера

(это как раз то место, где всё и «сыпется»):

bash
# На ВАШЕМ сервере (где xray слушает 443):
nc -vz 1.1.1.1 853
nc -vz cloudflare-dns.com 443
# Если Quad9 был недоступен:
nc -vz dns.quad9.net 443

Если dns.quad9.net:443 таймаутится, а Cloudflare — ок, то причина найдена.

БАЙПАС до вашего VLESS-сервера — обязателен

Не убирайте то, что уже добавили:

в tun.route_exclude_address: "85.192.63.245/32",
в route.rules выше всех общих правил:

json
{ "ip_cidr": ["85.192.63.245/32"], "outbound": "direct" }

И проверьте маршрутизацию:

bash
ip route get 85.192.63.245
# должно показать dev вашего реального iface (НЕ singtun0)

Перезапуск и быстрые тесты

bash
sing-box check -c /путь/к/config.json
sudo systemctl restart sing-box

# DNS через цепочку:
dig @127.0.0.1 example.org +time=2 +tries=1

# Убедиться, что на внешнем интерфейсе нет «сырого» 53:
sudo tcpdump -i enp2s0 -n port 53

Если теперь DNS ожил, проверяйте data-plane:

bash
curl -v https://ident.me/ --max-time 5

А что насчёт смены порта (443 → 2096/8443/2053)?

Имеет смысл, если именно ваш провайдер блокирует/шэйпит клиентское соединение к серверу на 443 (например, из-за сигнатур). Тогда:

Вариант 1 — добавить порт в Xray

На сервере в inbounds добавьте второй inbound с теми же настройками, но с другим портом, например 2096. Перезапустите Xray и в клиенте поменяйте:

json
"outbounds": [
  {
    "type": "vless",
    "tag": "proxy",
    "server": "85.192.63.245",
    "server_port": 2096,
    ...
  }
]

Вариант 2 — DNAT порта на сервере (если не хочется править Xray)

bash
# Проброс TCP 2096 → 443 на сервере
sudo iptables -t nat -A PREROUTING -p tcp --dport 2096 -j REDIRECT --to-ports 443
sudo iptables -t nat -A PREROUTING -p tcp --dport 8443 -j REDIRECT --to-ports 443

Плюс открыть порты в firewall/SG, если есть. На клиенте ставите server_port: 2096 (или 8443).

Но подчёркиваю: текущая ошибка — timeout к dns.quad9.net через прокси. Переключение порта клиента без смены DNS-апстрима не устранит «context deadline exceeded».

Если всё ещё «context deadline exceeded»

Пришлите небольшой набор:

20–30 строк sing-box (debug) вокруг одного запроса DNS после правок,
вывод ip route get 85.192.63.245,

и (по возможности на сервере) результат:

text
nc -vz 1.1.1.1 853
nc -vz cloudflare-dns.com 443
nc -vz dns.quad9.net 443

Тогда точечно добьём остатки.

Answer 5

Спасибо за подробные логи — они очень показательные.

Что именно сейчас ломается

Каждая DNS-заявка уходит как outbound/vless[proxy] … → 1.1.1.1:853, а потом падает context deadline exceeded.
Чуть позже видно первопричину: dial tcp 85.192.63.245:443: i/o timeout.

То есть клиенту sing-box периодически не удаётся установить TCP к твоему VLESS-серверу. Все «context deadline exceeded» по DNS — это лишь следствие: пока не поднят VLESS-канал, DoT/DoH через прокси не поедет.

С учётом TUN (auto_route:true, strict_route:true) это почти всегда означает маршрутную петлю: попытка соединиться с самим сервером случайно уходит в TUN/прокси и застревает. Чтобы исключить это на 100%, нужно принудительно послать трафик к серверу в обход TUN, строго через физический интерфейс.

Исправление (надёжно против петель)

1) Жёсткий маршрут ОС до сервера

Зададим статический маршрут к 85.192.63.245 через твой реальный шлюз/интерфейс (замени enp2s0 и 192.168.0.1 на свои значения, если отличаются):

bash
# посмотреть текущий дефолтный шлюз
ip route | awk '/default/ {print "GW="$3,"IF="$5; exit}'

# установить фиксированный маршрут до сервера
sudo ip route replace 85.192.63.245/32 via 192.168.0.1 dev enp2s0 metric 5

# проверить, что путь реально идёт НЕ через singtun0
ip route get 85.192.63.245

Сделай маршрут постоянным (через NetworkManager connection / systemd-networkd — как тебе удобно).

2) Принудительно привяжем «прокси-аутбаунд» к реальному интерфейсу

В outbounds для твоего vless добавь dial-поля (они как раз для этого и существуют):

json
{
  "type": "vless",
  "tag": "proxy",
  "server": "85.192.63.245",
  "server_port": 443,
  "uuid": "…",
  "flow": "xtls-rprx-vision",

  "bind_interface": "enp2s0",              // <- главная строчка
  "inet4_bind_address": "192.168.0.85",    // (опционально) IP твоего enp2s0

  "tls": {
    "enabled": true,
    "server_name": "github.com",
    "utls": { "enabled": true, "fingerprint": "chrome" },
    "reality": { "enabled": true, "public_key": "…", "short_id": "…" }
  }
}

bind_interface относится к Dial Fields и заставляет sing-box открывать сокет к серверу строго через указанный NIC, что обрубает петли под TUN. Документация: Dial Fields → bind_interface/detour/… (sing-box.sagernet.org)

У тебя уже включено route.auto_detect_interface:true, что «в общем случае» тоже должно предотвращать петли, но в TUN-сценариях это иногда не срабатывает. Прямой bind_interface надёжнее. Описание auto_detect_interface: «Привязывать исходящие соединения к дефолтному NIC, чтобы предотвратить петли под tun». (sing-box.sagernet.org)

3) Оставь байпас в TUN-inbound и в правилах

Ты уже добавлял исключение, но на всякий случай проверь, что оба есть и стоят выше общих правил:

в inbounds.tun.route_exclude_address: "85.192.63.245/32";

в route.rules:

json
{ "ip_cidr": ["85.192.63.245/32"], "outbound": "direct" }

NB: route_exclude_address — это про настройку ОС-маршрутов под TUN и работает не всегда идеально, поэтому мы дополнительно делаем OS-маршрут (п.1) и bind_interface (п.2). Это вместе закрывает тему даже при «капризном» TUN. Есть открытые тикеты про нестабильное поведение exclude-полей. (GitHub)

4) Временно переведи DNS «в обход» прокси для проверки

Пока чиним доступ к серверу, можно на 2–3 минуты поставить:

json
"dns": { "final": "dns_direct" }

и вернуть обратно на dns_proxy, как только VLESS-канал оживёт.

5) Приведи DNS к новому формату (чтобы ушли WARN)

Пример без доменных имён (никаких лишних резолвов «до того как»), плюс default_domain_resolver:

json
"dns": {
  "servers": [
    { "tag": "dns_proxy",  "address": "tls://1.1.1.1:853", "strategy": "prefer_ipv4", "detour": "proxy" },
    { "tag": "dns_direct", "address": "tls://1.0.0.1:853", "strategy": "prefer_ipv4", "detour": "direct" }
  ],
  "final": "dns_proxy"
},
"route": {
  "default_domain_resolver": "dns_direct",
  …
}

В 1.12+ старый DNS-формат и «legacy outbound DNS rules» депрекированы; переход на address: + domain_resolver — рекомендованный путь. (New Releases)
(Если используешь DoH по имени, у нового HTTPS-DNS серверa резолв самого хоста задаётся через Dial Fields domain_resolver, а не через устаревший address_resolver.) (sing-box.sagernet.org)

Проверка после правок

bash
sing-box check -c /путь/к/config.json
sudo systemctl restart sing-box

# Маршрут до сервера должен быть не через tun:
ip route get 85.192.63.245

# DNS-тест через цепочку:
dig @127.0.0.1 example.org +time=2 +tries=1

# И уже data-plane:
curl -v https://ident.me/ --max-time 5

Если после пунктов 1–2 ещё будет i/o timeout к 85.192.63.245:443, кинь одной строкой вывод:

ip route get 85.192.63.245

— и 10–15 свежих строк sing-box (debug) вокруг одного запроса. Тогда точечно посмотрим, что ещё цепляет маршрут.

Про смену порта с 443

Смысл есть, если именно твой провайдер душит исходящие к твоему серверу на 443. Тогда:

добавь на сервере второй inbound/порт (напр., 2096 или 8443) или сделай DNAT 2096→443;
в клиенте поменяй server_port.

Но текущий лог указывает прежде всего на петлю/маршрут на клиенте, а не на блокировку 443. Поэтому сначала зафиксируй путь к серверу (пп. 1–2).

Answer 6

Окей, вижу, почему всё «висит», и при этом ты прав — фиксить системный маршрут не обязательно. Можно оставить «всё через TUN» для приложений, но само подключение клиента к серверу (единственный «бутстрап»-трафик) должно выходить напрямую через физический интерфейс из процесса sing-box, иначе получается петля.

Сейчас по логам и по tcpdump на сервере:

Клиент постоянно пытается установить VLESS-сессию и затем послать DNS через прокси (outbound … → 1.1.1.1:853), но сессия не встаёт → context deadline exceeded.
На сервере видно массовые FIN к твоему клиентскому IP: Xray принимает соединение на 443 и сразу закрывает его. Это классический признак несовпадения REALITY/Vision/UUID/SNI/shortId (или потока). В таком случае клиент не «таймаутится» прямо на TCP-SYN, а «подвисает» дальше, когда не может завершить рукопожатие и начать передавать DNS.

Ниже — план, который не ломает твою модель «всё через singtun», но гарантирует, что sing-box сможет сам выйти к серверу «в обход TUN», и параллельно устраняет причины мгновенных закрытий на сервере.

1) Избежать петли без правок системных маршрутов

Нам достаточно ограничиться настройками в самом sing-box.

(А) Привязать исходящее «proxy» к реальному интерфейсу

В твоём outbounds для VLESS добавь dial-поля:

json
{
  "type": "vless",
  "tag": "proxy",
  "server": "85.192.63.245",
  "server_port": 443,
  "uuid": "…",
  "flow": "xtls-rprx-vision",

  "bind_interface": "enp2s0",
  "inet4_bind_address": "192.168.0.85",

  "tls": {
    "enabled": true,
    "server_name": "github.com",
    "utls": { "enabled": true, "fingerprint": "chrome" },
    "reality": { "enabled": true, "public_key": "…", "short_id": "…" }
  }
}

bind_interface заставит именно соединение к серверу идти через реальный NIC, не попадая в TUN. Всё остальное (трафик приложений) по-прежнему маршрутизируется TUN’ом.

(Б) Оставь два страховочных правила

Они действуют только на соединения, которые инициирует сам sing-box (а не приложения), так что «всё через TUN» не пострадает:

в inbounds.tun.route_exclude_address уже есть:
```
"85.192.63.245/32"
```

и в route.rules (выше общих правил):

json
{ "ip_cidr": ["85.192.63.245/32"], "outbound": "direct" }

Этого достаточно, без статических маршрутов ОС.

2) Починить REALITY/Vision на сервере (сейчас сервер сразу шлёт FIN)

Проверь inbound на сервере (Xray). Минимально корректный пример:

json
{
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "decryption": "none",
        "clients": [
          { "id": "YOUR-UUID", "flow": "xtls-rprx-vision" }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "github.com:443",
          "serverNames": ["github.com"],
          "privateKey": "SERVER-REALITY-PRIVKEY",
          "shortIds": ["SHORTID"]
        }
      },
      "sniffing": { "enabled": true, "destOverride": ["http", "tls"] }
    }
  ]
}

Проверь строго:

UUID на клиенте == clients[].id на сервере.
flow с двух сторон: "xtls-rprx-vision".
server_name (клиент) ∈ serverNames (сервер), напр. github.com.
public_key (клиент) соответствует privateKey (сервер). Если сомневаешься — сгенерируй пару заново:
```
bash
xray x25519
# privateKey -> в server.realitySettings.privateKey
# publicKey  -> в client.tls.reality.public_key
```
short_id (клиент) ∈ shortIds (сервер). Длина 8/16 (hex).

Если что-то из этого не совпадает, Xray принимает коннект и сразу закрывает (что ты видишь как FIN в tcpdump).

Полезно запустить на сервере в момент попытки коннекта:

bash
journalctl -u xray -n 200 -f

Обычно видно сообщения вида «short id not found / invalid user / reality handshake failed».

3) DNS — новый формат и «подстраховка»

Чтобы убрать WARN и исключить «курицу-яйцо», используй новый синтаксис и апстрим по IP:

json
"dns": {
  "servers": [
    { "tag": "dns_proxy",  "address": "tls://1.1.1.1:853", "strategy": "prefer_ipv4", "detour": "proxy" },
    { "tag": "dns_direct", "address": "tls://1.0.0.1:853", "strategy": "prefer_ipv4", "detour": "direct" }
  ],
  "final": "dns_proxy"
},
"route": {
  "default_domain_resolver": "dns_direct",
  ...
}

Пока чинится пункт 2, можно временно:

"dns": { "final": "dns_direct" }

и вернуть dns_proxy, когда VLESS оживёт.

4) Проверки по шагам

Перезапуск:

bash
sing-box check -c /путь/к/config.json
sudo systemctl restart sing-box

Убедись, что sing-box открывает TCP к серверу в обход TUN (за это отвечает bind_interface — дополнительной проверки маршрутов ОС не требуется).
На сервере (параллельно) смотри логи:

bash
journalctl -u xray -n 50 -f

При удачном рукопожатии не будет мгновенных FIN после SYN — TCP-сессии станут «длинными».

Когда VLESS встал, проверь:

bash
dig @127.0.0.1 example.org +time=2 +tries=1
curl -v https://ident.me/ --max-time 5

А что насчёт смены порта 443?

Можно, но это решает лишь случаи DPI/шэйпинга по 443 между клиентом и сервером. Твои текущие симптомы — именно закрытие на сервере (FIN), то есть проблема уровня конфигурации REALITY/Vision/UUID/SNI/shortId.
Если всё-таки хочешь добавить альтернативный порт (например, 2096):

На сервере добавь второй inbound с теми же параметрами на port: 2096 или DNAT 2096→443.
На клиенте поменяй server_port на 2096.
(Правила из пунктов 1–3 остаются прежними.)

Итог

Петлю мы убираем внутри sing-box через bind_interface + точечные правила (без «фикса пути» в ОС).
Сервер сейчас отстреливает соединения (FIN) — синхронизируй REALITY/Vision/UUID/SNI/shortId/privateKey/publicKey по чек-листу выше. После этого DNS через прокси начнёт отвечать, и TUN-режим останется полностью рабочим для остального трафика.

Если после правок сервер всё ещё шлёт FIN, скинь 10–20 строк journalctl -u xray вокруг попытки — там будет точная причина (short id / user / reality handshake).

Question

📝 Настройка DNS через sing-box + dnsmasq

Что мы сделали

Thought

Troubleshooting sing-box setup

Diagnosing VLESS connection issue

Investigating server connection issues

Investigating DNS configuration mismatch

Providing troubleshooting steps for DNS and VLESS issues

Providing troubleshooting steps in Russian

Answer

Что видно из логов

Быстрая диагностика (клиент)

Проверка/исправление на сервере (если есть доступ)

Временный «буфер» чтобы оживить резолв

Приведи в порядок порт 53/1053 (на выбор)

Вариант 1: sing-box на 1053, dnsmasq форвардит на 1053

Вариант 2: sing-box слушает 53, dnsmasq не нужен

Чек-лист «почему внезапно перестало»

Мини-план действий

Question

Thought

Analyzing sing-box configuration

Analyzing DNS hijack and connectivity

Evaluating outbound connection issue

Checking for routing loop

Troubleshooting routing and connection issue

Addressing timeout and connection failures

Answer

Что поправить (минимальный патч)

Быстрая проверка после правок

Question

Thought

Identifying DNS leak issue

Investigating connectivity issue

Investigating VLESS and connection reset

Investigating DNS routing issue

Investigating DNS leak issue

Providing updated config suggestions

Providing DNS leak fix and config

Answer

1) Обнови конфиг sing-box (новый формат DNS + байпас до сервера)

2) Жёстко пресечь утечки DNS на уровне хоста

nftables (современные системы)

iptables-nft (если удобнее iptables)

3) Перезапуск и проверки

4) Проверка data-plane через прокси (VLESS/REALITY)

Почему tcpdump видел 8.8.8.8

Question

Thought

Considering port changes

Troubleshooting connection timeouts

Checking server connectivity

Examining server and proxy setup

Guiding port change and DNS fix

Answer

Что именно падает сейчас

Поправляем DNS в sing-box (без деприкаций и без «зависаний»)

Вариант A (надёжный): DoT Cloudflare по IP (не требует резолва)

Вариант B (если хотите DoH): Cloudflare DoH с «подстраховкой»

Проверьте доступность апстримов с сервера

БАЙПАС до вашего VLESS-сервера — обязателен

Перезапуск и быстрые тесты

А что насчёт смены порта (443 → 2096/8443/2053)?

Вариант 1 — добавить порт в Xray

Вариант 2 — DNAT порта на сервере (если не хочется править Xray)

Если всё ещё «context deadline exceeded»

Question

Thought

Examining outbound connection issue

Investigating connection timeout

Requesting user action

Configuring outbound settings

Tracing the fix for failed connection

Answer

Что именно сейчас ломается

Исправление (надёжно против петель)

1) Жёсткий маршрут ОС до сервера

2) Принудительно привяжем «прокси-аутбаунд» к реальному интерфейсу

3) Оставь байпас в TUN-inbound и в правилах

Почему `tcpdump` видел 8.8.8.8