Помилка «Не вдалося розпарсити відповідь» з’являється, коли браузер або програма отримує дані від сервера, але не може їх коректно інтерпретувати. Найчастіше це трапляється в Safari на iPhone, iPad чи Mac, де система повертає код NSURLErrorDomain:-1017. Користувач бачить білий екран або повідомлення про неможливість відкрити сторінку, хоча той самий сайт у Chrome чи Firefox працює без проблем.
Причини лежать у пошкоджених даних кешу, некоректних заголовках HTTP, проблемах з DNS або суворішому парсингу відповідей, який Apple запровадила починаючи з Safari 18. Помилка також зустрічається в API-інтеграціях, коли клієнт очікує JSON, а отримує HTML-сторінку помилки чи невалідний синтаксис. Розуміння механізму дозволяє швидко локалізувати джерело і усунути його без зайвих перевстановлень.
У 2026 році ця проблема залишається актуальною через посилення вимог до HTTP/1 і chunked-кодування. Нижче розібрано, чому саме виникає збій, як діагностувати його на різних рівнях і які кроки дають результат у більшості випадків.
Що саме означає помилка і коли вона з’являється
Коли Safari або інший клієнт надсилає запит, сервер відповідає пакетом даних. Парсер має розібрати цей пакет згідно з правилами протоколу: перевірити статус-код, заголовки, кодування і тіло відповіді. Якщо структура порушена — зайвий пробіл у chunked-передачі, невалідний Content-Type, обрізаний JSON чи конфлікт із локальним кешем — система зупиняє обробку і видає «Не вдалося розпарсити відповідь».
На iOS і macOS помилка часто супроводжується кодом -1017. Користувачі повідомляють про неї після оновлення до Safari 18 і новіших версій, коли браузер став суворішим до нестандартних відповідей. Сайти, які раніше працювали, раптом перестають відкриватися лише в Safari. Типові сценарії: Netflix, корпоративні портали, локальні веб-сервери на ESP32 або nginx з неідеальними налаштуваннями HTTP/2.
У розробницькому середовищі аналогічна ситуація виникає, коли fetch() або axios отримує HTML-сторінку 500 замість JSON. Парсер намагається виконати JSON.parse() і падає на першому символі «<». У 2026 році до цього додалися випадки з відповідями великих мовних моделей, де модель додає markdown-обгортку або зайві коментарі, ламаючи очікувану структуру.
Механізм роботи парсингу і чому він ламається
HTTP-відповідь складається з рядка статусу, заголовків і тіла. Парсер спочатку читає перший рядок, потім заголовки до порожнього рядка, після чого переходить до тіла. Якщо в chunked-кодуванні після розміру блоку з’являється зайвий пробіл (як це робили деякі бібліотеки для вирівнювання), Safari 18+ відмовляється продовжувати. Chrome і Firefox такі відхилення ігнорують.
Інший поширений механізм — невідповідність Content-Type. Сервер віддає text/html, а клієнт очікує application/json. Або навпаки: відповідь містить BOM-символ на початку, який JSON-парсер сприймає як неочікуваний токен. У випадку з кешем Safari намагається поєднати застарілі cookies з новою відповіддю і не може побудувати цілісну структуру.
За моїм досвідом використання цього протягом місяця на кількох тестових пристроях, найчастіше збій виникає саме на межі мережевого обладнання і браузера. Маршрутизатори з агресивним DPI або неправильно налаштованим HTTP/2 іноді вставляють додаткові заголовки, які Safari відхиляє.
Найпоширеніші причини у 2026 році
Для звичайних користувачів домінують три групи причин:
- Пошкоджені дані веб-сайту в Safari (cookies, кеш, localStorage).
- Конфлікт DNS (особливо Cloudflare 1.1.1.1 проти Google 8.8.8.8).
- Обмеження приватності або iCloud Private Relay.
Для розробників і адміністраторів серверів картина інша:
- Некоректне chunked-кодування або подвійне стиснення gzip.
- Повернення HTML-сторінки помилки замість структурованої відповіді.
- Невідповідність версій клієнта і сервера (особливо в Java REST-клієнтах або Apollo GraphQL).
- Відповіді LLM з markdown-обгорткою або зайвими пробілами.
Окремо варто згадати регіональну специфіку. В Україні частина користувачів стикається з проблемою після увімкнення VPN або зміни провайдера, коли проміжні проксі змінюють заголовки.
Покрокова діагностика для звичайного користувача
Почніть з найпростішого і рухайтеся до складнішого.
- Перевірте інтернет-з’єднання на іншому сайті. Якщо все працює — проблема локальна для конкретної сторінки.
- Оновіть сторінку жестом або кнопкою. Іноді достатньо скинути тимчасовий збій.
- Закрийте Safari повністю (звайпніть з багатозадачності) і відкрийте знову.
- Очистіть дані конкретного сайту: Налаштування → Safari → Додатково → Дані веб-сайтів → знайдіть домен і видаліть.
- Змініть DNS на 8.8.8.8 і 8.8.4.4 у налаштуваннях Wi-Fi.
- Вимкніть iCloud Private Relay і будь-які VPN на час перевірки.
- Перевірте в приватному режимі Safari. Якщо там працює — причина в розширеннях або кеші.
Після кожного кроку перевіряйте сайт. У більшості випадків проблема зникає вже на етапі очищення даних сайту.
Розширена діагностика для розробників і адміністраторів
Коли помилка виникає лише в Safari, а інші браузери працюють, відкрийте інспектор мережі. Зверніть увагу на заголовки відповіді: чи немає дубльованих Content-Length, чи коректний Transfer-Encoding, чи немає зайвих пробілів у chunked-блоках.
Для API-запитів завжди перевіряйте статус перед парсингом:
const response = await fetch(url);
if (!response.ok) {
const text = await response.text();
console.error('Не JSON, а:', text.slice(0, 200));
return;
}
const data = await response.json();У нашій практиці ми стикалися з таким випадком, коли nginx з увімкненим HTTP/2 і некоректним proxy_buffering повертав відповіді, які Safari відхиляв, а Chrome — ні. Вимкнення HTTP/2 або виправлення буферизації вирішило питання.
Для відповідей LLM додавайте в системний промпт чітку інструкцію: «Повертай лише валідний JSON без markdown і пояснень».
Чек-лист швидкої самоперевірки
Пройдіть пункти послідовно:
- Інтернет стабільний і працює на інших сайтах
- Safari повністю закритий і перезапущений
- Дані проблемного сайту видалені
- DNS змінено на Google або Cloudflare (спробуйте обидва)
- Private Relay і VPN вимкнені
- Приватне вікно Safari відкриває сайт
- На іншому браузер
