Files

vitya 5cdedb376a wiki(nl-vds-3xui): ingest session 2026-06-05 — honest final state + lessons

- new sources/nl-vds-3xui-setup-2026-06-05.md (full chronicle; HONEST outcome:
  у реальных клиентов из РФ работает только plain VLESS 32030; Reality/MTProto/
  SOCKS не поднялись)
- new concepts/proxy-debugging-test-the-real-client.md (anti-pattern: own curl/
  standalone tests passed while user's real clients failed; overclaim + bad
  MSS-clamp fix that broke things)
- rewrote entities/nl-vds-3xui.md — removed false "Reality verified/fixed" &
  "mtg works" claims; honest status table; MSS-clamp removed
- caveat added to reality-pq concept (disabling PQ != working Reality for GUI
  clients); index.md + log.md updated

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-05 14:36:36 +03:00

4.5 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

Отладка прокси/VPN: свой короткий тест ≠ опыт пользователя

Анти-паттерн (как делать НЕ надо)

При отладке прокси-узла nl-vds-3xui я многократно заявлял «работает» на основании собственных изолированных тестов:

curl -x socks5h://127.0.0.1:PORT https://... через временный xray.exe,
короткое скачивание 10 МБ,
openssl s_client к порту.

Эти тесты проходили, а боевые клиенты пользователя (v2rayN на ПК, официальный Telegram, телефон) — не работали. Каждое такое «у меня работает» при «у меня не работает» от пользователя разрушало доверие и уводило от причины.

Почему короткие тесты врут

Другой путь. curl -x http://127.0.0.1:10808 шёл через системный прокси (v2rayN), а не через тестируемый инбаунд. Или мой отдельный xray.exe — это не запущенный пользователем v2rayN (тот же core, но другой процесс/конфиг/состояние).
Короткое vs устойчивое. Кратковременный коннект мог проходить, а реальное использование (много соединений, сессия минутами) — рушиться (актив-блокировки по состоянию, ретраи).
Камуфляж-путь vs рабочий. openssl к FakeTLS-порту (mtg) проходит, потому что отвечает fallback-релей на маскировочный домен — но это НЕ значит, что реальная MTProto-сессия держится. Аналогично REALITY: неаутентифицированный openssl получает cert dest (fallback), а аутентифицированный клиент висит.
«Доступен/пинг ОК» в GUI — пассивная проверка достижимости, не равна работающей сессии.

Правило

Источник истины — реальный клиент пользователя на его устройстве/сети, а не мой тест. Если пользователь говорит «не работает» — это данные; мои зелёные curl'ы их не отменяют.
Когда нельзя воспроизвести на боевом клиенте — изолировать переменные на реальном пути: закрыть конфликтующие клиенты (у ПК и телефона один внешний IP — пока Desktop держит прокси, телефон в tcpdump не отличить), смотреть tcpdump на сервере по конкретному соединению (дошёл ли SYN, идёт ли рукопожатие, где встаёт, есть ли ответные байты).
Не заявлять «работает» / «подтверждено», пока не подтверждено на боевом клиенте. Гипотезу называть гипотезой. (Отдельно ловить overclaim: «РКН режет 443» было выдано за факт без доказательства.)
Не вносить «лечебные» изменения на сервере по недоказанной гипотезе (MSS-clamp по MTU-догадке — сломал соединения; пользователь заранее говорил, что дело не в MTU).

Где встречалось

nl-vds-3xui-setup-2026-06-05 — Reality/MTProto «проходили» в моих тестах, не работали у пользователя.

4.5 KiB Raw Blame History Unescape Escape