DNS, IP, порти та мережа

Що таке IP-адреса і чим IPv4 відрізняється від IPv6?

IP-адреса (IP address) — число, за яким мережа впізнає конкретну машину: маршрут пакета будується саме по ньому, а доменне імʼя лише зручна обгортка зверху. Стара версія протоколу відводить під адресу 32 біти й записує їх чотирма десятковими октетами через крапку, кожен у межах 0–255. Новіша бере 128 біт і пише їх вісьмома групами по чотири шістнадцяткові цифри через двокрапку. Запис прийнято скорочувати: провідні нулі всередині групи не пишуть, а суцільний ланцюжок нульових груп замінюють на :: — причому такий пропуск в адресі дозволений рівно один, бо інакше відновити довжину пропущеного було б неможливо. Для тестувальника наслідок простий: хоч би що стояло в baseURL, запит зрештою піде на конкретне число, і всі сюжети «потрапив не туди» живуть саме на цьому рівні.

Чим 127.0.0.1 відрізняється від 0.0.0.0 і чому «локально працює, а в CI ні»?

Перша адреса — loopback: трафік на неї не залишає машину, а замикається всередині неї (у IPv6 ту саму роль грає ::1). Друга при прослуховуванні означає не якийсь один інтерфейс, а всі одразу. Звідси прикладна різниця: сервер, привʼязаний до loopback, бачать лише процеси тієї самої машини чи того самого контейнера, а привʼязаний до 0.0.0.0 — будь-хто, хто дістає машину по мережі. Класичне падіння в CI саме таке: сервіс піднято на loopback, локально все зелене, а ранер із сусіднього контейнера стукає ззовні й отримує відмову зʼєднання. У звіті це виглядає як мережева проблема, хоча насправді питання лише в тому, який інтерфейс слухає сервер.

localhost резолвиться то в IPv4, то в IPv6 — це правда?

Ні, і плутанина тут не в резолві. Специфікація спеціальних імен якраз гарантує зворотне: запит адреси для localhost-імені дає відповідну loopback-адресу і для IPv4, і для IPv6, а бібліотекам резолву це приписано як SHOULD. Тобто обидві адреси доступні за іменем, ніякої лотереї немає. Лотерея — у тому, куди клієнт піде першим: двостековий (dual-stack) клієнт надсилає запит AAAA раніше й свідомо тримає перевагу за IPv6, а якщо відповіді повернулися не в тому порядку, SHOULD витримати паузу, щоб цю перевагу не втратити. Тому сервер, який слухає лише 127.0.0.1, для такого клієнта просто мовчить — рятує або явна адреса в конфігу замість імені, або прослуховування обох сімейств. Той самий механізм породжує плаваючі тайминги: спроби зʼєднання навмисно не запускають одночасно (SHOULD NOT be made simultaneously), тож на кривій IPv6-мережі перше зʼєднання довго «думає», доки клієнт зробить фолбек на другу адресу, а після першого успіху решту спроб SHOULD скасувати.

Що таке приватні діапазони, як читати CIDR і навіщо потрібен NAT?

Три блоки — 10.0.0.0/8, 172.16.0.0/12 і 192.168.0.0/16 — зарезервовані під внутрішні мережі й у публічному інтернеті не маршрутизуються. Число після скісної риски — це CIDR-нотація: воно каже, скільки старших біт адреси закріплено за префіксом мережі, а решта біт лишається під адреси самих вузлів. Тобто /8 фіксує чверть 32-бітної адреси, /16 — половину, /24 — три чверті. Оскільки внутрішню адресу назовні предʼявити не можна, роутер підміняє її на свою публічну — це і є NAT (Network Address Translation). Для AQA це щоденний фон: домашня, офісна, CI- і docker-мережі живуть саме в цих блоках, а тікети на доступи описують діапазони тією самою CIDR-мовою — «дозволити з 10.0.0.0/8».

Що таке порт, сокет і ефемерний порт?

Порт (port) — 16-бітний номер у межах 0–65535; ним транспортний рівень розрізняє сервіси, що працюють на одній машині: адреса доводить до компʼютера, порт — до конкретної програми на ньому. Пара «адреса + порт» називається сокетом (socket), і ключова деталь у тому, що TCP-зʼєднання визначає не один сокет, а їхня пара — локальний і віддалений. Саме тому браузер тримає багато одночасних зʼєднань до одного сервера: кожне унікальне четвіркою «адреса й порт джерела → адреса й порт призначення», а локальний порт клієнту щоразу видає операційна система з тимчасового, ефемерного набору. IANA ділить простір на три частини: 0–1023 системні (well-known), 1024–49151 користувацькі (registered), 49152–65535 динамічні (private, вони ж ephemeral). Тонкість, на якій ловляться: реальний ефемерний діапазон задає операційна система, і він часто не збігається з рекомендованим, тож на цільовій машині його краще подивитися, а не процитувати таблицю.

Чому 8080 треба писати в адресі явно, а 443 ні, і звідки береться address already in use?

Для стандартних схем порт мається на увазі: коли підкомпонент порту порожній, http іде на 80, а https — на 443. Схеми, яка за замовчуванням веде на 8080, не існує — це просто ще один зареєстрований порт (у реєстрі він записаний як HTTP Alternate), тому dev-сервер на ньому доводиться прописувати в baseURL повністю. Набір типових портів, які AQA бачить постійно, невеликий: 80, 443, 22, 53, 3306, 5432, 6379, 27017, 8080. Друга половина питання — про фіксовані порти в тестах: якщо сюїта піднімає сервер на жорстко заданому порту, а попередній прогін не прибрав за собою, старт валиться з address already in use. Власника порту показує lsof -i :3000, доступність порту на віддаленому хості — nc -zv host 443. Лікується це двома шляхами: фреймворк підбирає вільний порт динамічно або набір вимагає чистого стану між прогонами — зупиняє сервер у teardown, а не сподівається, що той «сам звільниться».

З чого складається DNS і які записи варто знати напамʼять?

Формально система має три частини: простір доменних імен разом із ресурсними записами, сервери імен і резолвери. Простір імен — дерево, і повне імʼя вузла складається з міток на шляху від нього до кореня, які читають зліва направо: від найвужчої до найширшої. База розрізана на зони; сервер тримає повні дані лише про свою зону — для неї він авторитетний, — а решту може мати в кеші, і у відповіді він позначає, з якого джерела вона взялася. Це поле напряму придатне для діагностики: воно відрізняє «сервер знає» від «сервер згадав». Записи, з якими AQA стикається: A тримає IPv4-адресу імені, AAAA — IPv6-адресу, CNAME вказує канонічне імʼя для псевдоніма, NS перелічує сервери, авторитетні для зони, MX — сервери, куди йде пошта домену, а TXT везе довільний рядок (через нього підтверджують володіння доменом і публікують поштові політики). Найчастіші в роботі — A та AAAA (куди насправді летить трафік) і CNAME (чому імʼя стенда раптом веде на чужу інфраструктуру).

Опиши ланцюг резолюції домену з нуля.

Застосунок звертається не в мережу, а до бібліотеки резолюції своєї операційної системи — це stub-резолвер, і дерево він не обходить: усю чорнову роботу віддає рекурсивному серверу імен — своєму мережевому або сусідньому. Далі рекурсивний сервер іде згори: питає кореневі сервери, ті відкривають доступ до всього простору імен, але кінцевої адреси не знають і відсилають до серверів зони верхнього рівня; ті — до авторитетних серверів домену; і вже авторитетний віддає A-запис. Відповідь повертається до застосунку, і лише тоді відкривається зʼєднання. На практиці повний обхід трапляється рідко, бо майже кожну ланку хтось уже закешував — саме тому перший запит у прогоні дорожчий за решту, а час резолвінгу входить у час відкриття сторінки нарівні з іншими шарами.

Чи зобовʼязаний рекурсивний резолвер повернути кінцеву відповідь?

Ні — це один із найстійкіших переказів, і джерело каже прямо протилежне. Рекурсивний режим названо optional: сервер може його взагалі не надавати, може обмежити коло клієнтів, яким його надає, і формально він free to refuse рекурсію будь-кому або всім. Нерекурсивний режим, навпаки, must реалізувати кожен сервер імен. Навіть коли рекурсію надано, «кінцева відповідь» не гарантована: серед допустимих рекурсивних відповідей поряд із результатом і name error стоїть A temporary error indication. Справжня різниця режимів пролягає в іншому місці: рекурсивний сервер повертає або відповідь, або помилку, але ніколи не відсилання до іншого сервера. Прикладний висновок для прогону: тимчасова помилка резолюції — легальна відповідь, а не аварія, тож набір має її пережити, а не падати з висновком «мережа зламалась».

Що таке TTL і як його правильно обирати?

TTL (Time To Live) — верхня межа того, скільки відповідь дозволено тримати в кеші, перш ніж викинути; побачити його можна прямо у виводі dig +noall +answer. Кешування тут не оптимізація «за бажанням»: повносервісному резолверу локальний кеш із протуханням даних приписано як MUST, і зберігати можна не тільки вдалі відповіді, а й негативні на кшталт «такого імені немає». Вибір величини часто подають як симетричний компроміс, і це помилка: джерело асиметричне — короткий TTL мінімізує кешування, нульовий забороняє його зовсім, але орієнтир для типового вузла названо як should be on the order of days. Виняток прописано окремо: коли переїзд заплановано заздалегідь, TTL опускають до нього, щоб зменшити неузгодженість, а щойно все влаштувалося — піднімають назад. Тобто малий TTL — інструмент запланованого переїзду, а не нормальний робочий стан. Для тестів наслідок буквальний: після зміни адреси стенда прогін ще якийсь час стукатиме за старою, і чекати доводиться саме TTL — перезапуск сюїти тут не допомагає.

Файл hosts завжди перебиває DNS?

Ні, і формулювання специфікації обережніше за побутове уявлення: вузол може мати локальну таблицю хостів як резерв або доповнення до DNS, а те, що з двох джерел має пріоритет, лишено питанням конфігурації конкретного вузла, а не сталою нормою. Практичних висновків із цього два. Перший: прописати домен у hosts — зручний спосіб детерміновано направити тести на потрібний стенд, і він кращий за похід напряму за IP, бо імʼя в запиті лишається правильним. Другий: «я прописав, отже точно піде туди» — припущення, а не гарантія. Якщо тест уперто йде не туди, порядок джерел на цій машині чи в цьому образі треба перевірити, а не вважати відомим.

DNS ходить по UDP чи по TCP?

По обох, і на тому самому порту 53 — «порт 53 — це UDP» вже неточність. Далі важливо не переплутати документи. Базовий документ переваги транспорту не роздає взагалі: він каже лише, що запити везуть у UDP-датаграмах або по TCP-зʼєднаннях. Перевагу датаграмам дають інші документи — через менші накладні витрати й кращу продуктивність, і саме там зʼявляється формулювання «UDP is preferred over TCP for queries». Чинну ж модальність задає пізніший документ, що оновлює обидва старі: All general-purpose DNS implementations MUST support both UDP and TCP transport. Безумовне «спершу UDP» він при цьому послабив: вибір транспорту віддано резолверу — той MAY вирішувати за власними експлуатаційними міркуваннями, — а TCP там прямо названо повноцінною альтернативою, а не суто варіантом ретраю. Практичний наслідок: ставлення до TCP як до «запасного» шляху й фільтрація його на фаєрволі — та сама помилка, що ламає резолюцію на стендах.

Що таке truncated-фолбек і чому він цікавий тестувальнику?

Повідомлення, яке їде по UDP, обмежене 512 байтами. Довше обрізають і виставляють у заголовку біт TC; якщо обрізаною виявилася секція Answer, а запитувач уміє TCP, він SHOULD повторити запит уже по TCP. Поруч живе сусідній сюжет, де модальність ще жорсткіша: передача зони — не «перехід на TCP за потреби», а вимога, бо UDP для неї is not acceptable, а повний трансфер через AXFR завжди йде по TCP. Різниця у формулюванні тут і є змістом: «переходить, коли треба» описує вибір, must описує обовʼязок. Тестувальнику цей блок потрібен заради однієї конкретної гіпотези: якщо в мережі стенда заблоковано DNS-over-TCP, великі відповіді просто не дійдуть, а наслідок джерело формулює буквально: «resolution failure and/or application-level timeouts». Тобто звіт покаже таймаут застосунку, тоді як зламано конфігурацію мережі.

Чому звʼязок «домен ↔ IP» не один до одного і чому не варто ходити в тестах напряму за IP?

Несиметрія тут із трьох боків одразу. Один вузол може мати кілька інтернет-адрес — тоді в нього просто кілька A-записів. Багато доменів можуть жити за однією адресою: сервер розрізняє їх за заголовком Host, який везе хост і порт із цільового URI й дозволяє origin-серверу обслуговувати кілька імен на одній машині; користувацький агент MUST цей заголовок згенерувати, якщо не передає ту саму інформацію псевдозаголовком :authority. І той самий домен може вести на різні машини в різних місцях — так працює CDN (Content Delivery Network), що тримає копії даних і віддає їх із найближчого до користувача вузла. Звідси й відповідь на другу половину: похід за адресою обходить рівно ті механізми, на яких стоїть продукт. Можна не потрапити на потрібний віртуальний хост, а перевірка сертифіката ламається за самою нормою: клієнту приписано MUST звірити особу сервісу з тим origin-сервером, який названо в URI. Коли треба детерміновано влучити в конкретний стенд, правильний інструмент — локальна таблиця хостів, а не IP в адресному рядку.

Які гарантії дає TCP, як влаштоване рукостискання і чому HTTP/3 — виняток?

TCP (Transmission Control Protocol) дає застосунку надійний потік байтів зі збереженим порядком, і саме заради цього HTTP/1.1 та HTTP/2 стоять на ньому: HTML, JSON і картинка мають прийти цілими й у правильній послідовності. Механіка за цими словами така: потік їде сегментами, кожен окремою IP-датаграмою; втрату видно за номерами послідовності, пошкодження — за контрольними сумами, а лікує обидва випадки повторна передача. Нумерація наскрізна побайтова, тому підтвердження накопичувальне: ACK зі значенням X означає «усе до X отримано», причому сам X іще ні. Зверху на це накладено керування потоком і перевантаженням: швидкість підлаштовується так, щоб не поховати ні приймача, ні саму мережу. Ціна гарантій платиться на старті: перед першим корисним байтом іде тристороннє рукостискання (handshake) SYN → SYN-ACK → ACK, і кроків саме три, бо сервер склеює підтвердження клієнтового SYN зі своїм власним SYN в одне повідомлення; заразом сторони обмінюються початковими номерами послідовності. Для HTTPS поверх цього лягає ще й рукостискання TLS, тож до першого байта відповіді встигає пройти кілька обмінів «туди-назад» — звідси й сенс тримати зʼєднання відкритим (keep-alive), щоб не платити за це щоразу. Серед версій протоколу випадає один: HTTP/3 стоїть не на TCP, а на QUIC, який працює поверх UDP і забезпечує впорядковану надійну доставку власними механізмами.

Чим затримка відрізняється від пропускної здатності?

Це різні осі, а не два імені одного. Затримка (latency) — час, за який дані долають шлях від відправника до одержувача; на практиці мережеву затримку міряють у обидва боки, як round-trip delay: від моменту, коли джерело відправило перший біт запиту, до моменту, коли воно отримало останній біт відповіді. Пропускна здатність (bandwidth) — скільки інформації канал пропускає за одиницю часу, і міряють її кратними бітам за секунду. Що осі незалежні, видно вже із самого TCP: там існує добуток «пропускна здатність × затримка», і шляхи з великим добутком мають власну назву — long, fat network, тобто канал буває водночас товстим і довгим. Більшої пропускної здатності на такому шляху не досить: обсяг непідтверджених даних «у дорозі» обмежує вікно приймача. Для тестів різниця цілком прикладна: сценарій із десятками дрібних запитів ріже саме затримка, бо кожен ресурс платить свій час і вони складаються, а завантаження великого файла впирається в іншу характеристику — тривалість фази Receiving визначає сукупність пропускної здатності й розміру файла.

Скільки форм посередника означує HTTP і що таке interception proxy?

Три, а не дві: proxy, gateway і tunnel, причому терміна forward proxy у специфікації немає взагалі. Розрізняє їх не бік, з якого стоїть вузол, а те, хто його обрав і як він поводиться. Проксі — агент пересилання, якого обирає клієнт, зазвичай локальними правилами конфігурації; організації зводять через нього запити заради безпекових сервісів, сервісів анотації або спільного кешу. Шлюз (він же reverse proxy) визначається тим, що назовні поводиться як origin-сервер, а всередину транслює й пересилає запити далі; за ним і живуть кеш-прискорювач та розділення чи балансування навантаження між машинами — балансувальник тут окремий випадок шлюзу, а не «ще один вид проксі». Тунель — сліпий ретранслятор між двома зʼєднаннями: повідомлень він не змінює, учасником HTTP-обміну не вважається й зникає, щойно обидва кінці ретрансльованого зʼєднання закриють; типове застосування — протягнути TLS крізь спільний фаєрвольний проксі. Один і той самий вузол може перемикатися між цими ролями від запиту до запиту. Окремо стоїть interception proxy: його визначальна ознака протилежна до проксі — його не обирає клієнт, він фільтрує чи перенаправляє трафік на рівнях нижче застосунку, і специфікація оцінює його різко: на рівні протоколу такий вузол невідрізненний від атакувальника на шляху. Уразливий він і сам — коли бере хост із портом за ключ спільного кешу, не перевіривши, що перехоплене зʼєднання взагалі йшло на валідну адресу цього хоста.

502, 503 і 504 — усі три від посередника?

Ні, і плутанина коштує часу на діагностиці. 502 за означенням віддає сервер, який діє як шлюз або проксі й отримав невалідну відповідь від сервера за собою. 504 — той самий сервер у тій самій ролі, тільки причина інша: він не дочекався своєчасної відповіді від вищого сервера. А 503 про посередника не каже нічого: він означає, що сам сервер зараз не здатен обробити запит — тимчасове перевантаження або планові роботи. Читати їх тому треба по-різному: 502 і 504 показують пальцем на ланку за посередником, тож дивитися варто в бекенд і його доступність, а 503 — це сервер, який сам про себе сказав «зараз не можу», і перевіряти треба його стан та вікна релізів.

Що таке VPN за канонічним означенням і чого він не робить?

Канон визначає VPN (Virtual Private Network) широко: це загальна назва для практики, коли публічні чи приватні мережі використовують, щоб зібрати групу учасників, відрізану від решти мережі, усередині якої вони спілкуються між собою так, наче мають власну приватну мережу. Ключова деталь у продовженні означення: наскрізне шифрування там названо способом посилити це відокремлення, а не визначальною ознакою. Тобто побутове «VPN — це коли трафік шифрується» зміщує акцент: шифрування є підсиленням, а суть — членство в групі. Для AQA це не термінологічна прискіпливість, а пояснення механізму: корпоративний VPN відкриває внутрішні стенди не тому, що «щось зашифрував», а тому, що робить машину частиною відокремленої групи. Звідси й вимога до інфраструктури тестів: якщо ранер поза цією групою, до внутрішнього середовища він не достукається жодним підкручуванням таймаутів — доступ треба закладати в конфігурацію CI.

Тест періодично падає по таймауту на першому кроці. Як звузити причину?

Насамперед розкласти час запиту по шарах, а не гадати — це вміє curl через змінні --write-out: time_namelookup показує, скільки зайняв пошук імені, time_connect — доведення TCP-зʼєднання до кінця, time_appconnect — момент, коли добіг TLS, time_starttransfer — надходження першого байта відповіді. Головна пастка в читанні: усі чотири відлічуються від старту запиту, тому кожне наступне вже містить попереднє, і сенс мають різниці між сусідніми, а не абсолютні числа. connect − dns — це власне TCP-рукостискання, tls − connect — TLS, ttfb − tls — час, поки бекенд готував відповідь. Далі діагноз читається майже сам: великий перший доданок — «холодна» резолюція або застарілий запис із довгим TTL; обрив на connect — порт закритий чи недосяжний; великий приріст на TLS при швидкій відповіді після нього — проблема в рукостисканні, а не в застосунку. Оцінюють і порядок дій: спершу назвати шар, далі перевірити оточення, у якому живе прогін (чужий посередник, зарізаний транспорт, відсутній VPN), і тільки після цього чіпати код тесту. І окремо варто памʼятати, що фаза Waiting у мережевій панелі показує затримку самого сервера, а не мережі, тож ні більша пропускна здатність, ні перевикористання зʼєднань її не скоротять.

Три кейси про мережевий шар у щоденній роботі AQA: як за одну команду перетворити «падає по таймауту» на назву шару, як не наступити на пару address already in use плюс 127.0.0.1 vs 0.0.0.0 при піднятті сервера під тест, і як свідомо відтворити повільну мережу замість того, щоб чекати на неї. Скрізь — що саме дивитися і чому це значить те, що значить.

Кейс 1. Перетворюєш таймаут на назву шару

Прогін у CI раз на десять запусків падає на першому кроці, у застосунку жодної помилки, а локально все зелене. Питання «чи це баг продукту» ще навіть не поставлене — спершу треба знати, яка ланка зʼїла час: резолвінг імені, встановлення зʼєднання, TLS чи вже сам бекенд. curl розкладає це на чотири числа:

curl -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" \
     -o /dev/null -s https://app.example.com/login

dns=0.031 connect=0.052 tls=0.108 ttfb=0.216

Що дивитися і чому:

• Числа накопичувальні, а не окремі. Кожне відлічується від старту запиту, тому connect уже містить dns, а tls містить connect. Абсолютні значення тут майже нічого не кажуть — сенс мають різниці між сусідніми: connect − dns це TCP-рукостискання, tls − connect це TLS, ttfb − tls це час, поки бекенд готував відповідь.
• Роздутий перший доданок. Резолвінг — це або «холодний» кеш, або застарілий запис. Перевір dig +noall +answer app.example.com: у рядку відповіді видно і реальну адресу, і TTL, тобто скільки ще житиме стара версія, якщо стенд нещодавно переїхав. Чекати доводиться саме цей строк — перезапуск сюїти його не скорочує.
• Обрив або довга пауза на connect. Порт закритий чи недосяжний, і бекенд тут ні до чого. Найдешевша перевірка — nc -zv app.example.com 443.
• Великий приріст на TLS при швидкій відповіді після нього. Тобто tls − connect велике, а ttfb − tls мале: винне рукостискання, а не застосунок — після встановлення каналу сервер відповів миттєво.
• Останній шар узагалі не мережевий. Те, що панель показує фазою Waiting, — це затримка самого сервера: час від отримання запиту до початку відповіді. Її не лікують ні більшою пропускною здатністю, ні перевикористанням зʼєднань, і плутати її з мережевою затримкою — класична помилка в баг-репорті.

Висновок, який рятує години: якщо запас у таймауті менший за холодний резолвінг плюс два рукостискання, тест зрізає ще живий запит. Це не дефект застосунку, а занижений таймаут.

Окрема гіпотеза для корпоративних мереж: якщо гальмують не всі імена, а саме «важкі» відповіді, варто перевірити, чи не заблоковано DNS-over-TCP. Наслідок описаний у джерелі прямим текстом — «resolution failure and/or application-level timeouts», тобто симптомом буде таймаут застосунку, а причина лежатиме в конфігурації мережі.

Кейс 2. address already in use і 127.0.0.1 vs 0.0.0.0 у CI

Більшість e2e-наборів піднімає власний сервер під прогін, і саме тут живуть дві пастки з одного класу.

Перша — порт уже зайнято, найчастіше попереднім прогоном, який не прибрав за собою:

Error: listen EADDRINUSE: address already in use 127.0.0.1:3000

Власника порту видно локально однією командою:

lsof -i :3000

Друга пастка тонша й дає симптом, схожий на мережевий збій. Сервер на 127.0.0.1:3000 слухає loopback — трафік до нього не виходить за межі машини, тож із сусіднього контейнера він недосяжний узагалі. Сервер на 0.0.0.0:3000 слухає всі інтерфейси й доступний ззовні. Плутанина між ними і є найчастішою причиною «у мене працює, а в CI ні».

У Playwright обидві лікуються конфігурацією webServer:

// playwright.config.ts (фрагмент)
export default defineConfig({
  use: { baseURL: 'http://127.0.0.1:3000' },
  webServer: {
    command: 'npm run start -- --host 0.0.0.0 --port 3000',
    url: 'http://127.0.0.1:3000/health',
    reuseExistingServer: !process.env.CI,
    timeout: 60_000,
  },
});

Що дивитися і чому:

• url замість фіксованої паузи. Ранер опитує ендпоінт здоровʼя, поки той не відповість, і лише тоді стартує тести. Це очікування за умовою: на повільному CI сервер може прогріватися довше, і набір це переживе, а sleep на дві секунди — ні.
• --host 0.0.0.0 у контейнері. Привʼязка до всіх інтерфейсів, щоб ранер узагалі достукався. Локально 127.0.0.1 цілком достатньо, і зайвого відкриття назовні краще не робити.
• reuseExistingServer: !process.env.CI. Локально перевикористовуєш уже піднятий сервер і не ловиш EADDRINUSE між прогонами, а в CI щоразу піднімаєш чистий. Це прямий вияв ізоляції стану: набір або сам звільняє порт у teardown, або підбирає вільний динамічно, але ніколи не сподівається, що «саме розсмокчеться».
• Чому в baseURL стоїть адреса, а не імʼя. З резолвом localhost усе гаразд: імʼя чесно віддає обидві loopback-адреси. Вибирає між ними клієнт, і перевага в нього за IPv6 — тож коли сервер слухає лише IPv4, зʼєднання «незрозуміло чому» не встановлюється. Явна адреса знімає це питання цілком.
• Локальна таблиця хостів — не гарантія. Якщо ти направляєш прогін на стенд через hosts, памʼятай: специфікація називає її резервом або доповненням до DNS, а пріоритет лишає питанням конфігурації вузла. Тобто це хороший інструмент, але перевіряти, куди насправді пішов запит, усе одно доведеться.

Кейс 3. Свідомо відтворюєш повільну мережу

Гонки на таймінгах на швидкій машині розробника не відтворюються — вони просто не встигають статися. Щоб зловити їх навмисно, мережу треба або сповільнити, або замінити керованою підробкою. Обидва інструменти вбудовані у Playwright, і перехоплення відбувається всередині браузера — окремий проксі для цього не потрібен.

test('UI не розсипається, коли API повільний, а частина бекенду падає', async ({ page }) => {
  // штучна пауза перед фейковою відповіддю — імітуємо високу затримку
  await page.route('**/api/user', async (route) => {
    await new Promise((resolve) => setTimeout(resolve, 2000));
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ id: 1, name: 'Some User Name' }),
    });
  });

  // рідкісний стан, якого на живому стенді не дочекаєшся
  await page.route('**/api/orders', (route) => route.fulfill({ status: 500 }));

  await page.goto('/dashboard');
  await expect(page.getByText('Some User Name')).toBeVisible();
  await expect(page.getByText('Не вдалося завантажити')).toBeVisible();
});

Що дивитися і чому:

• Пауза імітує затримку, а не низьку пропускну здатність. setTimeout перед fulfill відтворює саме час подорожі — те, від чого страждають екрани з десятком дрібних викликів API: кожен платить свій час, і разом вони помітні. Для важких файлів картина інша: там тривалість визначає сукупність пропускної здатності й розміру, тож імітувати треба обсяг, а не паузу.
• Три різні дії на одному перехопленні. route.fulfill віддає підроблену відповідь (як тут — успіх і 500), route.abort обриває запит і показує, як UI переживає повністю мертвий ендпоінт, а route.continue пропускає запит далі, дозволивши підмінити лише сам запит — його URL, метод, заголовки чи тіло. Вибір між ними і є вибором того, який саме збій ти відтворюєш.
• Патерн маршруту звіряй із реальним запитом. Якщо **/api/user не збігається зі шляхом, який робить фронтенд, перехоплення мовчки не спрацює, а тест буде зелений із хибної причини. Дешева перевірка — подивитися фактичний URL у мережевій панелі.
• Очікування за умовою, а не за годинником. toBeVisible() чекає появу елемента. Двосекундна пауза тут — контрольований подразник на стороні мока, а не в тесті; фіксовані waitForTimeout у самому тесті першими зрізають перевірку на повільнішому ранері.
• Тротлінг (throttling) як другий інструмент. Нижчий клас зʼєднання в девтулзах емулюють трьома параметрами: скільки даних іде до клієнта, скільки від нього, і яку мінімальну затримку додати кожному запиту. Готові пресети не збігаються від браузера до браузера, а в Chrome ще й переїжджають від версії до версії — тому «повільна мережа» в баг-репорті без конкретних чисел майже нічого не означає. Надійніше завести власний профіль із зафіксованими значеннями. Поруч живе режим Offline: найдешевша перевірка того, чи повідомляє застосунок про втрату мережі взагалі.
• Що саме шукати на повільному профілі. По-перше, стани завантаження: чи взагалі показано індикатор і чи не блимає порожній екран замість нього. По-друге, гонки, яким на швидкому каналі бракує часу проявитися — найвідоміша з них дає подвійне надсилання, коли кнопку не блокують на час польоту запиту. Падіння тесту на такому профілі — не флак: тест на швидкому каналі просто ще не встиг упасти, бо очікування в ньому привʼязані до часу, а не до подій.
• І окремо — «а чи не стоїть щось між нами». Якщо поведінка відрізняється саме в офісній мережі, згадай: вузол, якого клієнт не обирав, на рівні протоколу невідрізненний від атакувальника на шляху й може фільтрувати чи перенаправляти трафік без відома відправника. Це перевіряють конфігурацією мережі, а не ще одним перезапуском прогону. Для повного контролю над трафіком поза браузером той самий принцип дає mitmproxy: показати справжні запити, підмінити відповідь, зімітувати помилку сервера.

Адреси й порти

• Знаю різницю IPv4 (32 біти, чотири октети 0–255) vs IPv6 (128 біт, вісім шістнадцяткових груп) і памʼятаю, що :: в адресі дозволено рівно один раз.
• Можу пояснити різницю loopback (127.0.0.1, ::1) vs 0.0.0.0 при прослуховуванні — і чому саме вона дає «локально працює, а в CI ні».
• Знаю пастку localhost: імʼя чесно дає обидві loopback-адреси, вибирає між ними клієнт, і перевага в нього за IPv6 — тож сервер лише на IPv4 для нього мовчить, а спроби зʼєднання навмисно не паралельні (звідси плаваючі тайминги).
• Можу прочитати CIDR (/16 — скільки старших біт закріплено за префіксом мережі), назвати три приватні діапазони (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) і пояснити роль NAT.
• Розумію різницю сокет (адреса + порт) vs зʼєднання (пара сокетів) і знаю, що локальний ефемерний порт видає операційна система — вона ж задає його реальний діапазон, а не таблиця IANA (0–1023 well-known, 1024–49151 registered, 49152–65535 dynamic).
• Памʼятаю типові порти (80, 443, 22, 53, 3306, 5432, 6379, 27017, 8080), причину, чому 443 можна не писати, а 8080 треба, і звідки береться address already in use у CI разом зі способами цього уникнути.

DNS: механіка й кеш

• Можу назвати три складники DNS (простір імен із записами, сервери імен, резолвери), пояснити зону й авторитетність і памʼятаю, що сервер позначає у відповіді, звідки вона — з власних даних чи з кешу.
• Знаю типи записів: A, AAAA, CNAME, NS, MX, TXT.
• Можу описати ланцюг резолюції (stub-резолвер ОС → рекурсивний сервер → кореневі → TLD → авторитетний) і знаю, що stub сам ієрархію не обходить, а кореневі сервери кінцевої адреси не знають.
• Знаю, що рекурсія — сервіс optional: сервер free to refuse, може обмежити коло клієнтів, а серед допустимих рекурсивних відповідей є A temporary error indication. Відрізняє рекурсивний режим те, що він ніколи не віддає відсилань.
• Можу пояснити TTL і асиметричну рекомендацію джерела (on the order of days для типового вузла; знижувати перед запланованою зміною й повертати після), а також те, що локальний кеш із протуханням даних — це MUST, і кешувати можна й негативні відповіді.

Транспорт DNS і джерела імен

• Можу сказати, хто саме віддає перевагу датаграмам, а хто просто перелічує обидва транспорти, памʼятаю, що порт 53 спільний для UDP і TCP, і знаю чинну модальність: MUST support both UDP and TCP transport, а TCP — не «варіант ретраю».
• Можу описати truncated-фолбек (512 байтів → біт TC → SHOULD повторити по TCP), знаю, що AXFR по TCP — вимога, а не «перехід за потреби», і що заблокований DNS-over-TCP дає «resolution failure and/or application-level timeouts».
• Знаю, що файл hosts — це резерв або доповнення до DNS, а пріоритет між ним і DNS джерело лишає питанням конфігурації вузла.

TCP, затримка, посередники

• Можу пояснити, чому звʼязок «домен ↔ IP» не один до одного (кілька A-записів, віртуальний хостинг за Host або :authority, CDN із найближчим вузлом) і чому похід за IP ламає перевірку сертифіката.
• Можу назвати гарантії TCP (надійність через номери послідовності й повторну передачу, порядок через накопичувальні ACK, контроль потоку й перевантаження), описати SYN → SYN-ACK → ACK і пояснити, чому кроків саме три; знаю, що HTTP/3 — виняток на QUIC поверх UDP.
• Можу розвести затримку (час подорожі, міряють як round-trip delay) і пропускну здатність (обсяг за час) і пояснити, чому її зростання затримки не скорочує (bandwidth × delay, long, fat network); не плутаю фазу Receiving (пропускна здатність і розмір файла) з фазою Waiting (затримка самого сервера) і памʼятаю, чому перший запит платить більше за наступні (резолвінг + TCP + TLS) і навіщо зʼєднання тримають відкритим.
• Знаю три форми посередника: проксі (обирає клієнт), шлюз/reverse proxy (назовні поводиться як origin-сервер, за ним живе балансування), тунель (сліпий ретранслятор). Терміна forward proxy в специфікації немає, а interception proxy — це вузол, якого клієнт не обирав, і на рівні протоколу він невідрізненний від атакувальника на шляху; звідси й читання кодів — 502/504 вказують на ланку за посередником, а 503 на сам сервер.
• Можу дати канонічне означення VPN (відокремлена група користувачів, що спілкується «ніби в приватній мережі») і памʼятаю, що шифрування там — посилення, а не визначальна ознака.
• Можу простежити відкриття https://app.example.com/login по шарах (резолвінг → TCP на 443 → TLS → HTTP із Host), розкласти час через curl -w і назвати інструменти перехоплення та тротлінгу (page.route у Playwright, mitmproxy, профіль мережі в девтулзах).