Помилка Cloudflare 522: тайм-аут з'єднання - причини і виправлення

Що означає помилка 522

Кожен проксійований запит починається з того, що Cloudflare відкриває TCP-з'єднання з вашим origin-сервером, перш ніж зможе надіслати сам HTTP-запит. Помилка 522 виникає, коли це рукостискання, TCP SYN і очікуваний у відповідь SYN-ACK, не завершується в межах вікна тайм-ауту Cloudflare. Origin-сервер може бути надто перевантажений, щоб приймати нові з'єднання, брандмауер може мовчки відкидати пакети замість того, щоб відхиляти їх, або мережевий шлях між Cloudflare і origin-сервером може бути перевантажений.

Це відрізняється від помилки 521, де origin-сервер активно відмовляє у з'єднанні, і від помилки 524, де TCP-з'єднання встановлюється успішно, а сама HTTP-відповідь так і не приходить вчасно. Помилка 522 - це саме збій на етапі рукостискання, ще до того, як узагалі надіслано HTTP-запит.

Як з'являється помилка 522

Відвідувачі бачать сторінку Cloudflare, "Error 522: connection timed out", з Ray ID. Запит curl до домену показує той самий статус приблизно через час тайм-ауту Cloudflare:

curl -I https://example.com
HTTP/2 522

Оскільки TCP-рукостискання так і не завершилося, жоден запит не дійшов до вашого застосунку, тож логи застосунку зазвичай порожні за період збою. Натомість дивіться на метрики рівня з'єднань: навантаження й CPU сервера на момент помилок, кількість встановлених і очікуючих з'єднань (ss -s чи netstat -an | grep SYN_RECV), а також логи брандмауера чи балансувальника навантаження на предмет відкинутих чи відфільтрованих пакетів на відповідному порту.

Що спричиняє помилку 522

• Origin-сервер перевантажений і не встигає приймати нові з'єднання. Високе навантаження на CPU, переповнена черга з'єднань чи вичерпаний пул воркерів - усе це до цього призводить.
• Брандмауер чи група безпеки мовчки відкидає SYN-пакети Cloudflare замість того, щоб надіслати TCP-скидання. Відкидання виглядає з боку Cloudflare точнісінько як повільний чи мертвий сервер, тоді як скидання натомість спричинило б помилку 521.
• Keepalive TCP вимкнено на origin-сервері, що збільшує плинність з'єднань та ймовірність того, що нове рукостискання почнеться саме в момент, коли сервер надто зайнятий, щоб його прийняти.
• IP-адреса origin-сервера не додана в білий список коректно там, де мережа вимагає явного білого списку, а не простого правила брандмауера, тож запити Cloudflare фільтруються ще до того, як досягнуть слухаючого сокета.
• Перевантаження мережі чи втрата пакетів між Cloudflare й origin-сервером, частіше на origin-серверах на споживчому чи сильно перепроданому хостингу.

522 проти 524

Обидва коди - тайм-аути, але вони трапляються в різних точках запиту. Помилка 522 трапляється до того, як надіслано будь-який HTTP-запит: саме TCP-рукостискання так і не завершується. Помилка 524 трапляється після: TCP-з'єднання встановлюється успішно, і Cloudflare надсилає HTTP-запит, але origin-сервер не встигає надіслати повну відповідь протягом 100 секунд. 524 зазвичай указує на повільний застосунок, наприклад ендпоінт генерації звітів, повільний запит до бази даних чи запит, ініційований за розкладом, що дійсно займає хвилини. Виправлення для 524 майже завжди - пришвидшити ендпоінт чи перенести повільну роботу з циклу запит-відповідь у фонове завдання, результат якого клієнт опитує; Enterprise-плани Cloudflare також можуть підняти ліміт у 100 секунд для конкретних маршрутів, але це лікує симптом, а не сам повільний ендпоінт.

Як зрозуміти, хто винен

522 майже завжди виникає на боці origin-сервера чи поруч із ним, оскільки власна мережа Cloudflare висококонсистентна й рідко буває джерелом тайм-ауту рукостискання. Корисне питання - чи origin-сервер повністю лежить, чи просто перевантажений трафіком із певних регіонів. Найшвидший спосіб перевірити - запустити HTTP-перевірку з кількох локацій одночасно: HTTP-перевірка HostTracker звертається до домену з контрольних точок у кількох країнах і повідомляє кожен результат окремо, тож патерн, де частина локацій отримує тайм-аут, а інші успішні, вказує на перевантажений сервер, що обробляє частину запитів, але не всі, тоді як однаковий тайм-аут усюди вказує на повністю мертвий origin-сервер чи брандмауер, що відкидає кожне з'єднання.

Як виправити помилку 522

Якщо ви відвідувач

1. Перезавантажте сторінку через якийсь час. Миттєвий сплеск навантаження чи короткий мережевий збій часто минають самі.
2. Перевірте сторінку статусу сайту, якщо вона є, на предмет відомого інциденту.
3. На вашому боці нема чого виправляти. Тайм-аут трапляється між Cloudflare і власним сервером сайту, а не у вашому браузері чи вашому з'єднанні з Cloudflare.

Якщо ви керуєте сайтом

1. Перевірте навантаження сервера й доступну пропускну спроможність з'єднань на момент збоїв: CPU, пам'ять і налаштовані ліміти з'єднань чи воркерів вебсервера (наприклад, worker_connections у nginx).
2. Підтвердьте, що ваш брандмауер чи група безпеки дозволяють опубліковані діапазони IP-адрес Cloudflare на відповідному порту, і що вони відхиляють скиданням, а не мовчки відкидають пакети - це принаймні перетворить 522 на легшу для діагностики 521.
3. Увімкніть keepalive TCP на вебсервері origin-сервера та будь-якому балансувальнику навантаження перед ним і перевірте, чи налаштування keepalive на рівні ОС не залишені за замовчуванням, набагато довшими, ніж насправді потрібно з'єднанню.
4. Якщо ваш хостинг чи хмарна мережа вимагає окремого явного білого списку IP-адрес, окремо від брандмауера, підтвердьте, що IP-адреса origin-сервера в ньому є.
5. Виміряйте час самого рукостискання напряму до origin-сервера, оминаючи Cloudflare, щоб побачити, чи затримка взагалі у досягненні вашого сервера:

   curl -v -H "Host: example.com" --connect-timeout 5 https://ORIGIN_IP/

   З'єднання, що зависає тут, підтверджує, що сам origin-сервер повільно приймає з'єднання, а не щось специфічне для Cloudflare.
6. Для повільних окремих ендпоінтів, а не загалом перевантаженого сервера, винесіть тривалу роботу (звіти, експорти, пакетні завдання) з циклу запиту у фонове завдання, яке клієнт опитує чи про яке отримує сповіщення, і розглядайте підвищення тайм-ауту в Cloudflare Enterprise лише як тимчасовий захід для маршрутів, які не можна швидко пришвидшити.

Як запобігти цьому

Сервер, що провалює рукостискання лише під пікове навантаження, пройде будь-яку ручну перевірку, яку ви запустите самі, оскільки ви навряд чи протестуєте його точно в момент, коли він перевантажений. HTTP-перевірка, що виконується за розкладом поза вашою мережею, ловить це вікно збою, навіть коли ніхто не спостерігає, а запуск її з кількох країн показує, чи це проблема глобальної пропускної спроможності, чи регіонального мережевого шляху.

Пов'язані помилки

• Помилка Cloudflare 520: невідома помилка - origin-сервер відповів, але відповідь була непридатною для використання.
• Помилка Cloudflare 521: вебсервер недоступний - origin-сервер відмовив у з'єднанні замість того, щоб не відповідати.
• Помилки сервера 5xx - загальна родина кодів статусу.
• 502 Bad Gateway - версія збою upstream, не специфічна для Cloudflare.

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

Скільки часу Cloudflare чекає, перш ніж показати помилку 522?

Приблизно 15 секунд на TCP-рукостискання. Якщо origin-сервер не прийняв з'єднання за цей час, Cloudflare здається і повертає відвідувачу 522.

Чи означає 522 те саме, що мій сервер вимкнено?

Не завжди. Це також може означати, що сервер увімкнений, але надто зайнятий, щоб вчасно прийняти нове з'єднання, або що брандмауер відкидає спробу з'єднання, не надсилаючи скидання.

Чому брандмауер відкидає, а не відхиляє з'єднання?

Деякі конфігурації брандмауера чи групи безпеки за замовчуванням мовчки відкидають пакети, що не збігаються з дозвільним правилом, замість надсилання TCP-скидання. Саме це мовчазне відкидання перетворює те, що могло б бути швидкою і зрозумілою помилкою 521, на повільнішу й неоднозначнішу 522.

Чи означає 522, що мені потрібно оновити сервер?

Не обов'язково. Перед масштабуванням перевірте, чи вимкнено keepalive, чи брандмауер мовчки відкидає діапазони Cloudflare, і чи ліміти з'єднань у конфігурації вебсервера не встановлені нижче, ніж насправді вимагає трафік.

Яка різниця між 522 і 524?

522 - це збій навіть завершити TCP-рукостискання. 524 - це завершене з'єднання, де сама HTTP-відповідь займає надто багато часу, зазвичай через повільну логіку застосунку, а не через мережеву проблему чи брак потужності.

Чи може один повільний запит до бази даних спричинити 522?

Не напряму, оскільки 522 трапляється до того, як узагалі надіслано будь-який запит. Повільний запит до бази даних, найімовірніше, спричинить 524, де з'єднання встановилося успішно, але відповідь надходила надто довго.