Мережа WSL пояснена: чому localhost працює (і чому іноді ні)

February 6, 2026 • February 6, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ви запустили сервіс у WSL, відкрили http://localhost:3000 у браузері Windows, і він спрацював. Ви кивнули, ніби ваше життя під контролем.
Потім ви перезавантажилися, підключили VPN або «оптимізували» щось, і localhost почав поводитися так, ніби ніколи вас не знав.

Мережа WSL не містить містики. Це просто багатошарова система. Мережа Windows плюс Linux VM (WSL2), плюс допоміжна логіка, що намагається зробити робочий процес розробника «рідним».
Коли всі шари погоджуються, localhost здається магічним. Коли ні — ви отримуєте тайм-аути, відмову в з’єднанні або найгірше: працює на вашій машині й ламається у всіх інших.

Ментальна модель: що насправді означає «localhost» у WSL

«Localhost» — це не місце. Це ім’я інтерфейсу, яке розширюється до IP-адреси — зазвичай 127.0.0.1 для IPv4 і ::1 для IPv6.
Ключова операційна деталь: 127.0.0.1 завжди означає «ця мережева простір імен» (network namespace). Не «ця машина». Не «цей ноутбук». Не «те, що я емоційно мав на увазі».

На чистому Linux на фізичному хості «ця мережева простір імен» збігається з мережею хоста. У WSL2 Linux працює всередині легкої віртуальної машини з власним мережевим стеком.
Це означає:

Всередині WSL: localhost — це сама VM WSL.
Всередині Windows: localhost — це Windows.

Причина, чому це часто все ще працює — Windows додає «клею»: автоматичну переадресацію портів для доступу по стилю localhost, плюс (у новіших збірках) режим дзеркалювання мережі, який зменшує розрив.

Ваша задача як оператору — перестати думати в категоріях «машини» й почати думати в термінах стеків:
Хто є клієнтом? Який стек містить сервер? На якому інтерфейсі слухає сервіс? Який брандмауер у шляху? Який NAT або проксі виконує трансляцію?

Цікаві факти й історія, які можна використати

WSL1 не мав VM. Він транслював системні виклики Linux у виклики NT-ядра, тому мережа поводилася ближче до «рідної Windows з Linux-персоною».
WSL2 перейшов на справжнє ядро Linux. Чудово для сумісності; мережа стала мережею VM (NAT за замовчуванням), і саме тут народжується більшість історій «чому localhost не працює».
127.0.0.1 визначений як loopback. Пакети до нього ніколи не виходять на дріт; вони повертаються всередині стеку. Саме тому брандмауери й маршрутизація можуть поводитися інакше, ніж ви очікуєте.
Hyper-V — це вже не тільки для серверів. WSL2 використовує компоненти Hyper-V навіть на ноутбуках, тому ви бачите адаптер vEthernet і віртуальний комутатор у схемі.
Windows додав переадресацію localhost для WSL2. Windows може слухати порт на Windows і переспрямовувати трафік у WSL VM, тож localhost:порт «просто працює» з Windows-додатків.
Ця переадресація умовна. Вона може зламатися через політику брандмауера, адреси прив’язки, фільтри VPN або сервіси, що слухають тільки на 127.0.0.1 всередині WSL.
IPv6 — тихий порушник спокою. Багато інструментів віддають перевагу IPv6, якщо він доступний. Якщо ваш сервіс слухає тільки IPv4, а клієнт пробує ::1, отримаєте заплутані відмови.
DNS у WSL часто генерується автоматично. WSL може перезаписувати /etc/resolv.conf. «Виправлення DNS» вручну може працювати до наступного перезапуску, тоді отримаєте повторний збій.
Існує режим дзеркалювання мережі. У деяких версіях Windows/WSL можна віддзеркалити мережу хоста у WSL, зменшуючи дивність NAT і роблячи вхідний доступ передбачуванішим.

WSL1 vs WSL2: той самий термінал — інша планета

WSL1: трансляція системних викликів, без окремого мережевого стеку

Процеси WSL1 ділили мережевий стек з Windows. Коли процес у WSL1 слухав 127.0.0.1:8000, це фактично був той самий loopback, що й у Windows.
Це робило «localhost» простим і водночас робило деякі Linux-мережеві припущення хибними (бо це не зовсім Linux).

WSL2: VM з NAT за замовчуванням

WSL2 запускає справжнє ядро Linux у VM. VM отримує власну IP-адресу, зазвичай у приватній підмережі за віртуальним комутатором.
Windows — це хост. Linux — гість. NAT — за замовчуванням.

Це означає:

З WSL, вихідний доступ (в інтернет або LAN) зазвичай працює нормально завдяки NAT.
З Windows до WSL, вхідний доступ — складніша частина, бо ви переходите між стеком хоста та стеком гостя.
З LAN до WSL, вхідний доступ ще складніший, бо ви проходите кордон стеків і NAT.

Маршрути трафіку: Windows → WSL, WSL → Windows, WSL → LAN

Клієнт Windows → сервер у WSL

Типовий «dev loop»: ви запускаєте вебсервер у WSL (python -m http.server), потім відкриваєте його з Windows.
Це може працювати через переадресацію localhost або напряму через IP-адресу VM WSL.

Операційно вам потрібно знати, який шлях ви використовуєте:

Використовуючи localhost з Windows: ви покладаєтесь на те, що Windows робить переадресацію портів у WSL.
Використовуючи IP WSL VM: ви обходите частину магії, але тепер питання брандмауера і змін IP — ваша турбота.

Клієнт WSL → сервер Windows

Часто: інструменти в WSL спілкуються з сервісами Windows (SQL Server, локальні проксі, корпоративні агенти).
WSL зазвичай може дістатися до Windows через спеціальний nameserver або шлюз за замовчуванням. Деякі налаштування також використовують імена на кшталт host.docker.internal (не гарантовано скрізь).

Сервер у WSL → клієнти LAN

Саме тут люди будують «швидкі демо», що перетворюються на напівпродакшн. Ви хочете, щоб колеги в LAN заходили на сервіс у WSL.
Під NAT ви або:

Використовуєте Windows як вхідну точку та переадресовуєте трафік у WSL (portproxy або вбудована переадресація), або
Перемикаєтесь на режим дзеркалювання (якщо доступний і підходить), або
Перестаєте прикидатися і запускаєте сервіс на належній VM/хості/контейнерній платформі для публічного доступу в LAN.

Чому localhost працює (коли працює)

Коли ви вводите localhost:PORT у браузері Windows і сервіс з WSL відповідає, ви зазвичай користуєтесь можливістю Windows виявляти порти, що слухають у WSL,
і переадресовувати підключення з Windows loopback у WSL VM.

Успішний сценарій зазвичай вимагає:

Сервіс слухає на інтерфейсі WSL, доступному з Windows (часто 0.0.0.0 або IP WSL VM; іноді 127.0.0.1 працює залежно від версії та поведінки переадресації).
Жодне правило брандмауера Windows не блокує вхідне з’єднання на цей порт/інтерфейс.
Жоден VPN/фільтр не перехоплює або не змінює loopback/VM трафік так, щоб це ламало переадресацію.
Клієнт і сервер погоджуються щодо IPv4 або IPv6.

У режимі дзеркалювання історія змінюється: WSL може ділити мережу хоста більш безпосередньо, тож прив’язка до 0.0.0.0 у WSL може поводитися більш як «прив’язка до хоста».
Це ближче до того, чого люди зазвичай очікують.

Жарт №1: Якщо ви коли-небудь почуваєтеся непридатним, пам’ятайте, що є люди, які прив’язують сервіси до 127.0.0.1 і дивуються, чому LAN не може їх досягти.

Чому localhost іноді не працює

Збої групуються за кількома категоріями. Більшість — самостійного виробництва. Решта — «ваш корпоративний стек для кінцевих точок робить щось хитре».

1) Сервіс прив’язаний до неправильної адреси

Прив’язка до 127.0.0.1 всередині WSL означає «лише в межах мережевого простору WSL».
Якщо переадресація Windows не активна або не переадресовує таку прив’язку, додатки Windows не дістануться до сервісу.
Прив’язка до 0.0.0.0 (усі інтерфейси) всередині WSL частіше є правильним рішенням для доступу через межі стеків.

2) Перевага IPv6 перетворює “localhost” на ::1

Деякі клієнти резольвлять localhost як до ::1, так і до 127.0.0.1 і намагаються IPv6 першою.
Якщо ваш сервіс лише IPv4, ви можете отримати миттєву «connection refused», хоча IPv4 би працював.

3) Windows Firewall (або корпоративні контролі) блокує це

Багато інженерів вважають loopback «вільним від брандмауера». Це в більшості випадків вірно на одному стеку. Але трафік WSL2 може проходити через віртуальні інтерфейси, де застосовуються профілі брандмауера.
Домашні/доменні політики можуть також посилювати доступ до loopback і локальних портів у несподіваний спосіб.

4) VPN-клієнти та фільтрувальні драйвери ламають маршрутизацію/переадресацію

VPN можуть:

Переписувати DNS і правила роздільної маршрутизації так, що WSL не слідує за ними автоматично.
Встановлювати фільтри, що перешкоджають трафіку через Hyper-V віртуальний комутатор.
Вимикати поведінки «локального доступу в LAN» або трактувати vEthernet адаптери як ненадійні.

5) IP WSL змінився

IP-адреси VM WSL2 можуть змінюватися після перезапусків. Якщо ви хардкодите IP VM у клієнті Windows — ви створюєте часову бомбу.
Віддавайте перевагу переадресації localhost (якщо вона стабільна), режиму дзеркалювання або стабільним правилам переадресації на боці Windows.

6) Ви «оптимізували» мережевий стек

Вимикання сервісів, підміна генерації resolv.conf, маніпуляції з iptables/nftables або зміни конфігурації WSL можуть створити локально консистентну, але глобально зламану поведінку.
Дебаг пізніше відчувається як читання роману, де лиходій — ваше минуле «я».

Швидкий план діагностики

Мета — не «зрозуміти все». Мета — знайти вузьке місце за менше ніж п’ять хвилин і з доказами.

Перше: визначте, який стек відмовляє

Зсередини WSL: чи дістаєте сервіс через WSL localhost?
З Windows: чи дістаєте сервіс через Windows localhost?
З Windows: чи дістаєте сервіс через IP WSL VM?

Це розділяє проблему на «сервіс не слухає» проти «проблема переадресації/брандмауера/NAT».

Друге: підтвердьте адресу прив’язки і слухача

Перевірте, на яку адресу/порт сервер прив’язаний у WSL (вивід ss).
Перевірте, чи Windows слухає/переадресовує цей порт (вивід netstat у Windows).

Третє: перевірте два брандмауери і VPN

Правила брандмауера у WSL (iptables/nftables), якщо ви їх застосовуєте.
Профіль/правила Windows Firewall для порту й інтерфейсу.
Підключений VPN? Якщо так, протестуйте з вимкненим VPN (або в іншій мережі) для ізоляції.

Четверте: DNS лише після перевірки з’єднання

Не починайте з DNS, якщо симптом — відмова за з’єднанням імені. Якщо IP-з’єднання не працює, DNS не має значення.

Практичні завдання: команди, виводи та рішення

Команди нижче можна запускати для діагностики. Кожен блок містить, що означає вивід і яке рішення приймати.
Міксуйте за потребою. Це робота SRE: вимірюйте, не вгадуйте.

Завдання 1: Переконайтеся, що ви на WSL1 або WSL2

cr0x@server:~$ uname -r
5.15.133.1-microsoft-standard-WSL2

Значення: Якщо рядок ядра містить microsoft-standard-WSL2, ви в WSL2 з мережею VM.

Рішення: Припускайте поведінку NAT/переадресації. Не сприймайте localhost як спільний з Windows без перевірки.

Завдання 2: Знайдіть IP WSL

cr0x@server:~$ ip -brief addr show eth0
eth0             UP             172.24.85.101/20 fe80::215:5dff:fe12:3456/64

Значення: eth0 WSL має приватну IPv4-адресу. Це адреса, якою Windows може напряму дістатися до WSL.

Рішення: Використовуйте цей IP для прямого тесту з Windows. Не хардкодьте його в довготривалій роботі, якщо не готові до змін.

Завдання 3: Підтвердіть, що сервіс справді слухає (і де)

cr0x@server:~$ ss -ltnp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:3000      0.0.0.0:*     users:(("node",pid=2123,fd=19))

Значення: Сервіс слухає тільки на 127.0.0.1:3000 всередині WSL. Це loopback тільки в мережевому просторі WSL.

Рішення: Якщо Windows не дістає сервіс, переналаштуйте сервіс на прив’язку до 0.0.0.0 (або до IP WSL), коли потрібен доступ за межами стеку.

Завдання 4: Переприв’язати dev-сервер на всі інтерфейси (приклад)

cr0x@server:~$ python3 -m http.server 8000 --bind 0.0.0.0
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Значення: Сервер слухає на всіх IPv4-інтерфейсах, а не тільки на loopback.

Рішення: Тепер протестуйте з Windows, використовуючи IP WSL і (за потреби) переадресацію Windows localhost.

Завдання 5: Тест зсередини WSL через localhost

cr0x@server:~$ curl -sS -D- http://127.0.0.1:8000/ | head
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.12
Date: Tue, 06 Feb 2026 18:22:11 GMT
Content-type: text/html; charset=utf-8
Content-Length: 1093

Значення: Сервіс працює всередині WSL. Додаток у порядку.

Рішення: Якщо Windows не дістає його, зосередьтеся на межі: переадресація, брандмауер, VPN, IPv6.

Завдання 6: Тест зсередини WSL до Windows через шлюз за замовчуванням

cr0x@server:~$ ip route | head -n 3
default via 172.24.80.1 dev eth0
172.24.80.0/20 dev eth0 proto kernel scope link src 172.24.85.101

Значення: Шлюз за замовчуванням (часто інтерфейс хоста) — це 172.24.80.1.

Рішення: Коли WSL потрібно дістатися до сервісу Windows, ця адреса-шлюз — хороша перша спроба.

Завдання 7: Перевірте конфігурацію DNS у WSL

cr0x@server:~$ cat /etc/resolv.conf
nameserver 172.24.80.1
search corp.example

Значення: WSL вказує DNS на резолвер, який надав хост. Зміни VPN можуть вплинути на здатність цього резолвера обробляти корпоративні імена.

Рішення: Якщо з пошуком імен проблеми, але IP-з’єднання працює, виправте DNS (або інтеграцію з VPN). Не чіпайте DNS, якщо само з’єднання ламається.

Завдання 8: Швидка перевірка розв’язування імен

cr0x@server:~$ getent hosts github.com | head -n 1
140.82.121.4   github.com

Значення: Розв’язування DNS працює принаймні для цього запиту.

Рішення: Якщо проблема — «не можу дістатися сервісу за іменем», спробуйте IP сервісу. Якщо і це не працює — фокусуйтеся на DNS/VPN/resolv.conf.

Завдання 9: Перевірте, чи WSL може дістатися LAN (перевірка маршрутизації та NAT)

cr0x@server:~$ ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.9 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Значення: Вихідна конективність працює. NAT і маршрутизація не зовсім зламані.

Рішення: Якщо вхід з Windows у WSL не працює, при цьому вихід працює — ймовірно проблема в брандмауері/переадресації/прив’язці.

Завдання 10: Підтвердьте стан слухача на боці Windows зсередини WSL (швидка перевірка)

cr0x@server:~$ nc -vz 172.24.80.1 445
Connection to 172.24.80.1 445 port [tcp/microsoft-ds] succeeded!

Значення: Ви можете дістатися служби Windows (SMB у цьому прикладі) на IP шлюзу.

Рішення: Якщо WSL зовсім не дістає служби Windows, підозрюйте політики VPN/брандмауера на хості або проблеми з віртуальним комутатором.

Завдання 11: Перевірте правила WSL-брандмауера (iptables), якщо ви їх використовуєте

cr0x@server:~$ sudo iptables -S | head
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Значення: Політики за замовчуванням ACCEPT; сам WSL не блокує вхід.

Рішення: Якщо політики DROP/REJECT — виправте їх або тимчасово очистьте правила під час налагодження. Якщо ACCEPT — переходьте до брандмауера/переадресації на боці Windows.

Завдання 12: Перевірте, чи є слушачі тільки для IPv6 або тільки для IPv4

cr0x@server:~$ ss -ltn | grep -E ':3000|:8000'
LISTEN 0      4096   0.0.0.0:8000   0.0.0.0:*
LISTEN 0      4096   [::1]:3000     [::]:*

Значення: Порт 8000 слухає на IPv4 всі інтерфейси; порт 3000 слухає тільки на IPv6 loopback.

Рішення: Якщо клієнт Windows намагається IPv4 і терпить невдачу, увімкніть IPv4-прив’язку або явно тестуйте IPv6, де це доречно.

Завдання 13: Перевірте переадресацію Windows→WSL, використавши тест по IP WSL (з перспективи WSL)

cr0x@server:~$ curl -sS -D- http://172.24.85.101:8000/ | head
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.12
Date: Tue, 06 Feb 2026 18:24:51 GMT
Content-type: text/html; charset=utf-8
Content-Length: 1093

Значення: Сервіс відповідає на IP WSL VM. Це добре для прямого доступу з Windows і для будь-яких механізмів переадресації.

Рішення: Якщо localhost:8000 у Windows не працює, але IP WSL працює з Windows — проблема саме в переадресації localhost.

Завдання 14: Впіймайте помилку «працює на WSL localhost, але не на eth0»

cr0x@server:~$ curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
200

cr0x@server:~$ curl -sS -o /dev/null -w '%{http_code}\n' http://172.24.85.101:3000/
curl: (7) Failed to connect to 172.24.85.101 port 3000 after 0 ms: Connection refused

Значення: Сервіс слухає тільки на loopback. Ось чому підключення через IP VM дає помилку.

Рішення: Переналаштуйте адресу прив’язки сервісу. Не «виправляйте» брандмауер для сервісу, який насправді не слухає там, де ви думаєте.

Завдання 15: Визначте інтерфейс і MTU (пов’язані дивності з VPN)

cr0x@server:~$ ip link show eth0 | sed -n '1,2p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:12:34:56 brd ff:ff:ff:ff:ff:ff

Значення: MTU — 1500. Якщо корпоративний VPN обрізає MTU і WSL не узгоджує його, ви можете отримувати «деякі сайти працюють, деякі зависають».

Рішення: Якщо підозрюєте MTU black hole, тестуйте з меншими пакетами (або налаштуйте MTU), замість того щоб випадково змінювати DNS.

Завдання 16: Швидка перевірка шляху пакетів за допомогою traceroute

cr0x@server:~$ traceroute -n -m 3 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 3 hops max, 60 byte packets
 1  172.24.80.1  0.295 ms  0.260 ms  0.250 ms
 2  192.168.1.1  1.987 ms  1.912 ms  1.901 ms
 3  1.1.1.1      9.812 ms  9.766 ms  9.742 ms

Значення: Ви бачите шлюз хоста, потім LAN-шлюз, потім пункт призначення. Це очікуване для NAT-стилю конекту.

Рішення: Якщо перший хоп не відповідає — ваша віртуальна мережа WSL зламана. Якщо другий хоп падає тільки під VPN — винен VPN/маршрутизація.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Продуктова команда збудувала внутрішнє демо середовище на Windows-ноутбуках, бо закупівля затягувався, а дедлайн — ні.
Стек складався з невеликого API у WSL2, десктоп-клієнта Windows і браузерного адмін UI. В офісі все працювало прекрасно.

Потім команда поїхала на майданчик до клієнта. Ноутбук підключився до іншої мережі, увімкнувся корпоративний VPN, і адмін UI помер.
API все ще працював. curl у WSL повертав 200. Але браузер Windows отримував тайм-аути на localhost.

Неправильне припущення: «localhost завжди локальний». Вони припустили, що оскільки Windows міг дістатися WSL через localhost в одному середовищі, це стабільний контракт.
Насправді вони покладалися на поведінку переадресації, яку частково зламав фільтрувальний драйвер VPN.

Виправлення було простим. Вони змінили dev-сервер, щоб прив’язуватися до 0.0.0.0, перевірили доступ через IP WSL і додали правило portproxy на Windows для портів демо.
Також задокументували запасний варіант: якщо потрібен VPN — використовувати режим дзеркалювання де підтримується або запускати браузер у WSL (Linux), щоб не переходити межу стеків.

Справжній урок: якщо ваша система залежить від зручної фічі, ставте її як залежність. Тестуйте під VPN, політикою брандмауера й при зміні мережі — інакше вона вас «протестує».

Міні-історія 2: Оптимізація, що відпрацювала назад

Інша команда мала повільні завантаження залежностей у WSL. Хтось «оптимізував DNS», прописавши вручну /etc/resolv.conf на публічний резолвер і вимкнувши авто-генерацію.
Завантаження пришвидшились. Всі пораділи і продовжили. Саме так роблять помилки.

Через два тижні інженери не могли розв’язати внутрішні імена з WSL, коли були під корпоративним VPN.
Windows вирішував їх добре. WSL міг дістатися IP-адрес. Але будь-яке ім’я виду internal.service.corp падало.

Оптимізація відпрацювала назад, бо WSL обходив хост/VPN-резидентний DNS. VPN очікував, що внутрішні імена розв’язуються через корпоративні резолвери.
Windows підпорядковувався. WSL ігнорував. Результат — флот ноутбуків, де внутрішні сервіси «раптом» почали відмовляти.

Відкат був простим: відновили авто-генерацію DNS у WSL і навчили людей вимірювати, а не робити cargo-cult.
Для продуктивності вирішили справжню проблему: кешування, mirror-репозиторії артефактів і винос повторних завантажень з «гарячого шляху».

Жарт №2: Нічого не є більш постійним, ніж тимчасова правка DNS «тільки на сьогодні», яка «просто зробила все швидше».

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда платформи стандартизувала локальну розробку для великого репозиторію. Вони не боролися з WSL; написали маленький скрипт «перевірки мережі» і включили його в онбординг.
Він перевіряв прив’язки слухачів, виводив IP WSL, підтверджував, що Windows може дістатися ключових портів, і попереджав про IPv6-only слухачів.

Через місяць Windows-оновлення змінило поведінку віртуалізації й профілі брандмауера.
Половина організації почала скаржитися, що «dev API впав», бо localhost з Windows перестав діставати WSL у деяких людей.
Інша половина не мала проблем, бо звісно все було непослідовно.

Скрипт перевірки перетворив хаос на триаж. Інженери могли швидко й послідовно відповісти:
«Сервіс слухає тільки на loopback WSL.» Або «Windows Firewall блокує переспрямований порт.» Або «Ваш VPN перехоплює vEthernet адаптер.»

Команді платформи не знадобилися героїчні зусилля. Потрібна була порівнянність: ті самі перевірки, ті самі виводи, ті самі подальші рішення.
Виправлення розгорнули як зміну конфігурації (за замовчуванням прив’язки, плюс документований портproxy fallback) і одноразове правило брандмауера Windows для dev-портів.

«Нудне, але правильне» масштабується. «Працює на моїй машині» — це не стратегія; це признання.

Типові помилки: симптом → корінь → виправлення

1) Симптом: Браузер Windows не може дістатися сервісу WSL на localhost, але curl у WSL працює

Корінь: Сервіс прив’язаний до 127.0.0.1 всередині WSL, і переадресація Windows→WSL не обробляє це (або заблокована).
Виправлення: Прив’язати до 0.0.0.0 (або IP eth0 WSL). Повторно протестувати через IP WSL з Windows. Якщо потрібен localhost — налаштуйте явну переадресацію на боці Windows (і правило брандмауера).

2) Симптом: `curl http://localhost:PORT` на Windows падає, але `curl http://WSL_IP:PORT` працює

Корінь: Шлях переадресації localhost зламаний (оновлення Windows, брандмауер, фільтрувальний драйвер VPN або відключена інтеграція).
Виправлення: Використовуйте IP WSL для локального тестування або налаштуйте стабільний Windows-слухач, що переадресовує у WSL. Якщо доступний режим дзеркалювання і підходить — розгляньте його.

3) Симптом: Працювало до підключення VPN, потім WSL втратив розв’язування імен

Корінь: DNS у WSL вказує туди, куди не може розв’язуватися під політикою VPN, або resolv.conf був змінений вручну і обходить корпоративний DNS.
Виправлення: Відновіть авто-генерацію /etc/resolv.conf WSL. Якщо політика вимагає — використовуйте резолвер, що надає VPN, або налаштуйте DNS по інтерфейсу у підтримуваний спосіб.

4) Симптом: Випадкові тайм-аути, особливо при великих завантаженнях, тільки в певних мережах

Корінь: Невідповідність MTU або проблеми path MTU discovery через VPN, тунелі або фільтрування.
Виправлення: Тестуйте з меншими пакетами; вирівняйте MTU, де можливо. Якщо не можете контролювати — обійдіть проблему (інша мережа, політика split-tunnel або режим дзеркалювання, якщо він змінює шлях).

5) Симптом: Пристрої LAN не можуть дістатися сервісу в WSL, але Windows може

Корінь: Межа NAT. VM WSL недоступна напряму з LAN, і Windows не переадресовує порт зовні.
Виправлення: Виставте порт на Windows (вхідне правило брандмауера + переадресація у WSL). Або припиніть використовувати WSL для сервісів, що потребують доступу з LAN, і розгорніть на справжньому середовищі.

6) Симптом: «Connection refused» замість тайм-ауту

Корінь: Немає слухача на цьому IP:порті (неправильна прив’язка, невірний порт, невідповідність IPv6/IPv4).
Виправлення: Перевірте слухачів за допомогою ss -ltnp. Виправте адресу прив’язки. Якщо слухач існує лише на IPv6 — тестуйте [::1] або увімкніть IPv4.

7) Симптом: «Timeout» замість відмови, але сервіс слухає

Корінь: Падіння пакета брандмауером (Windows Firewall, захист кінцевої точки, політика VPN) або зламана маршрутна доріжка.
Виправлення: Тестуйте з Windows на IP WSL; перевірте правила брандмауера; тимчасово відключіть VPN для ізоляції. Не міняйте додаток, поки не доведете, що пакети доходять до VM.

Контрольні списки / поетапний план

Чекліст A: Ви хочете, щоб Windows-додатки надійно діставалися до сервісу у WSL

Прив’язуйте розумно: налаштуйте сервіс у WSL, щоб слухати на 0.0.0.0 (або IP WSL), а не тільки на 127.0.0.1.
Підтвердьте локально: з WSL виконайте curl http://127.0.0.1:PORT і curl http://WSL_IP:PORT.
Тест з Windows по IP WSL: якщо це падає — у вас проблема брандмауера або маршрутизації. Виправте це перед тим, як покладатися на магію localhost.
Визначте спосіб доступу:
- Віддавайте перевагу Windows localhost forwarding, коли воно стабільне у вашому середовищі.
- Якщо ні — налаштуйте явну переадресацію на Windows і задокументуйте її.
Захистіть для корпоративної реальності: тестуйте з підключеним і відключеним VPN; протестуйте на гостьовій Wi‑Fi один раз.

Чекліст B: Ви хочете, щоб пристрої LAN дісталися до чогось у WSL

Запитайте «чи варто?» Якщо це більше ніж демо — розгорніть належно.
Якщо йдете далі: відкрийте порт на Windows (вхідне правило брандмауера + переадресація у WSL).
Виберіть стабільний порт: не використовуйте ефермерні високі порти, що конфліктують з інструментами розробки.
Логи й моніторинг: якщо сервіс важливий — додайте хоча б access logs і health endpoint.

Чекліст C: DNS-проблеми під VPN

Спочатку перевірте IP-з’єднання. Якщо не можете пропінгувати IP — DNS не головна проблема.
Перевірте генерацію /etc/resolv.conf. Якщо він зафіксований вручну — очікуйте дрейфу й болю.
Перевіряйте розв’язування через getent. Це тестує системний резолвер, а не лише одне інструментальне налаштування.
Узгоджуйте з політикою. Якщо корпоративний VPN вимагає корпоративного DNS — не «фіксуйте» це публічними резолверами і надійтеся.

Часті питання

1) Чи WSL2 — фактично VM? Чи треба його так сприймати?

Так. Це легка віртуальна машина з реальним ядром Linux. Сприймайте мережу як мережу VM: окремий стек, NAT за замовчуванням і межа, що вимагає явної обробки.

2) Чому Windows іноді може дістатися сервісів WSL через localhost?

Windows може переадресовувати з’єднання з Windows loopback у WSL. Коли це працює — здається, що localhost спільний. Коли ні — ви нагадуєте собі, що це не так.

3) Чому прив’язка до 127.0.0.1 у WSL ламає доступ з Windows?

Бо 127.0.0.1 — це loopback для мережевого простору WSL, а не для Windows. Якщо переадресація не транслює таку прив’язку, Windows не дістане сервіс. Для доступу між стеком прив’язуйте до 0.0.0.0.

4) Чи завжди треба прив’язувати dev-сервери до 0.0.0.0 у WSL?

Якщо вам потрібен доступ з Windows (або LAN) — так. Якщо потрібен лише внутрішній доступ у WSL — прив’язка до loopback дає меншу експозицію. Вирішуйте свідомо, а не за звичкою.

5) Чому це ламається лише при підключенні VPN?

VPN змінює маршрути, DNS і іноді встановлює фільтрувальні драйвери, що перешкоджають віртуальним адаптерам. Якщо збій корелює з VPN — ізолюйте, вимкнувши VPN і порівняйте маршрути й DNS.

6) Чому localhost іноді резольвиться в IPv6 і ламає мій сервіс?

Багато клієнтів віддають перевагу IPv6 і першими пробують ::1. Якщо ваш сервіс лише IPv4 — отримаєте помилки, хоча IPv4 би працював. Забезпечте, щоб сервіс слухав на обох, або тестуйте явно з 127.0.0.1.

7) Чи можна зробити IP WSL статичним?

У моделі NAT за замовчуванням IP WSL VM може змінюватися. Ви можете створити автоматизацію для виявлення, використовувати переадресацію на боці Windows або режим дзеркалювання. «Статичний IP WSL» зазвичай — пастка.

8) Чому WSL може дістатися інтернету, але Windows не може дістатися WSL?

NAT полегшує вихідний трафік. Для входу потрібні слухачі, правильні прив’язки та правила брандмауера. Різний напрям — різні правила. Діагностуйте вхідні з’єднання окремо.

9) Чи завжди режим дзеркалювання кращий?

Він може зменшити плутанину і спростити вхідний доступ, але також змінює експозицію і по-іншому взаємодіє з корпоративними політиками мережі. Тестуйте в вашому середовищі, перш ніж стандартезувати.

10) Яка операційна звичка запобігає більшості мережевих збоїв WSL?

Завжди перевіряйте «де я слухаю?» за допомогою ss -ltnp і завжди тестуйте з обох сторін (WSL і Windows) перед тим, як оголошувати перемогу.

Висновок: практичні подальші кроки

Мережа WSL передбачувана, коли ви припиняєте надавати localhost людських якостей. У WSL2 ви переходите через межу віртуальної машини.
Іноді Windows згладжує це. Іноді VPN, політика брандмауера або невинна прив’язка повертають вас до реальності.

Подальші кроки, що дійсно витримаються в продакшн-подібних dev-сценаріях:

Стандартизувати прив’язки слухачів: для сервісів, що мають бути доступні з Windows, прив’язуйте до 0.0.0.0 у WSL і задокументуйте це.
Прийняти швидкий план діагностики: WSL localhost, Windows localhost, IP WSL. Не імпровізуйте.
Тестувати під VPN: якщо ваша організація його використовує, він — частина «нормального», а не крайній випадок.
Віддати перевагу нудним інструментам: невеликий скрипт перевірки, що виводить слухачів, IP і стан DNS, заощаджує години слідчої роботи у Slack.

«Надія — це не стратегія.» — генерал Ґордон Р. Салліван