vitya
5cdedb376a
- 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>
37 lines
4.5 KiB
Markdown
37 lines
4.5 KiB
Markdown
---
|
||
title: Отладка прокси — проверять на реальном клиенте, не на своих curl-тестах
|
||
type: concept
|
||
tags: [troubleshooting, methodology, proxy, vpn, vless, reality, mtproto, anti-pattern]
|
||
sources: [../sources/nl-vds-3xui-setup-2026-06-05.md]
|
||
updated: 2026-06-05
|
||
---
|
||
|
||
# Отладка прокси/VPN: свой короткий тест ≠ опыт пользователя
|
||
|
||
## Анти-паттерн (как делать НЕ надо)
|
||
|
||
При отладке прокси-узла [`nl-vds-3xui`](../entities/nl-vds-3xui.md) я многократно заявлял «работает» на основании **собственных изолированных тестов**:
|
||
- `curl -x socks5h://127.0.0.1:PORT https://...` через временный `xray.exe`,
|
||
- короткое скачивание 10 МБ,
|
||
- `openssl s_client` к порту.
|
||
|
||
Эти тесты **проходили**, а боевые клиенты пользователя (v2rayN на ПК, официальный Telegram, телефон) — **не работали**. Каждое такое «у меня работает» при «у меня не работает» от пользователя разрушало доверие и уводило от причины.
|
||
|
||
## Почему короткие тесты врут
|
||
|
||
1. **Другой путь.** `curl -x http://127.0.0.1:10808` шёл через системный прокси (v2rayN), а не через тестируемый инбаунд. Или мой отдельный `xray.exe` — это **не** запущенный пользователем v2rayN (тот же core, но другой процесс/конфиг/состояние).
|
||
2. **Короткое vs устойчивое.** Кратковременный коннект мог проходить, а реальное использование (много соединений, сессия минутами) — рушиться (актив-блокировки по состоянию, ретраи).
|
||
3. **Камуфляж-путь vs рабочий.** `openssl` к FakeTLS-порту (mtg) проходит, потому что отвечает fallback-релей на маскировочный домен — но это НЕ значит, что реальная MTProto-сессия держится. Аналогично REALITY: неаутентифицированный `openssl` получает cert dest (fallback), а аутентифицированный клиент висит.
|
||
4. **«Доступен/пинг ОК» в GUI** — пассивная проверка достижимости, не равна работающей сессии.
|
||
|
||
## Правило
|
||
|
||
- **Источник истины — реальный клиент пользователя на его устройстве/сети, а не мой тест.** Если пользователь говорит «не работает» — это данные; мои зелёные curl'ы их не отменяют.
|
||
- Когда нельзя воспроизвести на боевом клиенте — **изолировать переменные на реальном пути**: закрыть конфликтующие клиенты (у ПК и телефона один внешний IP — пока Desktop держит прокси, телефон в tcpdump не отличить), смотреть `tcpdump` на сервере по конкретному соединению (дошёл ли SYN, идёт ли рукопожатие, где встаёт, есть ли ответные байты).
|
||
- **Не заявлять «работает» / «подтверждено», пока не подтверждено на боевом клиенте.** Гипотезу называть гипотезой. (Отдельно ловить overclaim: «РКН режет 443» было выдано за факт без доказательства.)
|
||
- Не вносить «лечебные» изменения на сервере по недоказанной гипотезе (MSS-clamp по MTU-догадке — **сломал** соединения; пользователь заранее говорил, что дело не в MTU).
|
||
|
||
## Где встречалось
|
||
|
||
- [`nl-vds-3xui-setup-2026-06-05`](../sources/nl-vds-3xui-setup-2026-06-05.md) — Reality/MTProto «проходили» в моих тестах, не работали у пользователя.
|