Налаштування кешування WordPress і Cloudflare, які не порушують роботу wp-admin

Найважливіші правила

Кеш на краю — це грубий інструмент. WordPress — тонкий механізм, побудований на cookie, стані користувача та часових
токенах (nonce), які захищають форми й дії. Якщо ви кешуєте неправильну відповідь, ви не просто повертаєте застарілий HTML — ви повертаєте
неправильний HTML невірній людині, і WordPress це помітить. Часто голосно.

Правило 1: ніколи не кешуйте автентифіковані або станозалежні відповіді

На практиці «автентифікований» означає «має cookie авторизації WordPress», а «станозалежний» — це «cookie корзини/оплати/сесії»
або сторінки, які містять nonce. Якщо запит несе cookie, що змінюють те, що поверне походження, ви повинні обходити кеш.
Ви все ще можете кешувати статичні ресурси для залогінених користувачів; просто не кешуйте HTML.

Правило 2: кешуйте публічний HTML лише коли можете довести, що він публічний

«Cache Everything» підходить, якщо ви поєднуєте його з жорсткими правилами обходу на основі cookie і шляхів. Без правил обходу
це призводить до кешування відповідей з /wp-admin/ і їхньої видачі наступній людині, яка запитає. Таке трапляється. Це не весело.
Ваша модель загроз має включати «доброзичливе кешування» як потенційного противника.

Правило 3: використовуйте невелику кількість чітких правил, а потім спостерігайте

Не будьте архітектором собору з 47 правил на першій день. Почніть з: (1) обходу адмінки/входу, (2) обходу коли cookie вказують на
залогін, (3) агресивного кешування статичних ресурсів, (4) кешування публічного HTML з розумним TTL і планом очищення. Потім вимірюйте
коефіцієнт попадань (hit rate) і навантаження на походження.

Правило 4: якщо ви не можете пояснити рішення кешу, ви не зможете ним керувати

Кожна поведінка кешу має відповідати спостережному сигналу: заголовку (CF-Cache-Status), рядку логу, cookie або збігу шляху.
Якщо єдиний спосіб «налагодити» — натиснути обновити і сподіватися, ви не керуєте кешем. Ви керуєте ігровим автоматом.

Жарт #1: Кешування просте, поки не стає складним — трохи як DNS, але з більшою кількістю можливостей змусити ваш сайт вас обдурити.

Цікаві факти та коротка історія

• Факт 1: nonce в WordPress не є криптографічними nonce; це часові токени для захисту від CSRF з вікном дії.
• Факт 2: cookie wordpress_logged_in_ — найпростіший надійний сигнал, що запит не слід обслуговувати з публічного кешу.
• Факт 3: Багато плагінів WordPress додають власні cookie (A/B-тести, банери згоди, аналітика). Деякі — нешкідливі; інші змінюють вивід сторінки.
• Факт 4: «Cache Everything» на Cloudflare спочатку став популярним як обхід для кешування HTML на сайтах без зворотного проксі на кшталт Varnish.
• Факт 5: константа DONOTCACHEPAGE у WordPress існує тому, що навіть серверні кеші не можуть безпечно вгадати, коли сторінка персоналізована.
• Факт 6: Edge Cloudflare враховує певні заголовки кешу, але «враховує» і «робить саме те, що ви думаєте» — різні речі, якщо не тестувати.
• Факт 7: Дивовижна кількість інцидентів «wp-admin повільний» насправді спричинені конкуренцією за CPU на походженні від PHP-воркерів, а не затримками мережі.
• Факт 8: Очищення кешу — операційно дороге. Навіть коли воно «миттєве», воно може зруйнувати ваш коефіцієнт попадань і спричинити лавинне навантаження на походження.
• Факт 9: Фрагменти корзини WooCommerce (історично через ?wc-ajax=get_refreshed_fragments) часто спричиняють плутанину з кешуванням і часткову персоналізацію.

Що означає «не порушувати роботу wp-admin»

Поріг — не просто «wp-admin завантажується». Поріг — це: логін працює, дії з nonce працюють, редиректи не зациклюються, попередній перегляд показує актуальний контент,
завантаження медіа відбувається, редактори не бачать сесій інших користувачів, і кеш не підмітає приватні дані. Це мінімальна прийнятна безпека.

Ось що найчастіше ламається при недбалих правилах кешування:

• Редирект-лупи при вході: /wp-login.php постить, встановлює cookie, а потім край видає кешовану відповідь, яка ігнорує новий стан cookie.
• Застарілий адмін-інтерфейс: кешування /wp-admin/ або відповідей admin-ajax. Один кешований «Вам не дозволено» може зіпсувати годину роботи.
• Проблеми з попереднім переглядом і редактором: посилання на попередній перегляд містять параметри, схожі на nonce; їх кешування надійно покаже вчорашній чернетку як «актуальну».
• Витік персоналізованої панелі інструментів: кешування публічних сторінок без урахування, що залогінені користувачі отримують injected адмін-бар.
• Проблеми з корзиною WooCommerce: кешування сторінок корзини/оформлення або фрагментів приводить до «фантомних» корзин і заяв у службу підтримки.

Якщо ваша конфігурація кешу не вміє виразити «кешувати лише коли відсутні state cookie», ви не готові кешувати HTML.
На щастя, Cloudflare це може виразити — просто робіть це свідомо.

Базові налаштування Cloudflare для WordPress (безпечні значення за замовчуванням)

Чистий базовий набір: кешуйте статичні ресурси жорстко, не кешуйте адмінку або вхід, і кешуйте публічний HTML тільки якщо у вас є правила обходу за cookie.
Все інше — гарнір.

1) Агресивно кешуйте статичні ресурси

Їх безпечно кешувати на краю навіть для залогінених користувачів, бо вони не змінюються під користувача (якщо ви не робите щось дуже креативне з CSS, що окрема розмова).

• Зображення: .png .jpg .jpeg .gif .webp .svg
• CSS/JS: .css .js
• Шрифти: .woff .woff2 .ttf .otf

Використовуйте довгі TTL у браузері з версіонованими іменами файлів. Ядро WordPress і багато тем вже додають query string; краще — хешовані імена файлів, але не дозволяйте перфекціонізму зупинити прогрес.
Якщо ви не можете fingerprint-ити ресурси, тримайте помірний TTL у браузері і покладайтеся на край.

2) Обходьте кеш для шляхів адмінки та входу

Це безальтернативно:

• /wp-admin/*
• /wp-login.php
• /wp-json/* (принаймні для автентифікованих контекстів; публічні кінцеві точки можна кешувати по справі)
• /xmlrpc.php (ідеально — блокувати, якщо не використовується; якщо використовується — не кешувати)
• /wp-admin/admin-ajax.php (не кешувати)

3) Обходьте кеш коли існують певні cookie

Edge Cloudflare не «розуміє» WordPress, але може співставляти cookie. Ось великі:

• wordpress_logged_in_* → користувач автентифікований
• wordpress_sec_* → авторизація в адмінці по SSL
• wp-postpass_* → захищені паролем пости
• Cookie WooCommerce: woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*
• Деякі плагіни для членства встановлюють власні cookie; ідентифікуйте та додайте їх

4) Визначтеся, що робити з HTML

У вас є два розумних варіанти:

1. Консервативно: не кешувати HTML на Cloudflare взагалі. Кешувати лише статичні ресурси. Використовувати origin page cache (плагін, Nginx FastCGI cache або зворотний проксі) для HTML. Це опція «хочу передбачувану поведінку».
2. Кешування HTML на краю: кешувати публічний HTML на Cloudflare з жорсткими правилами обходу. Це опція «хочу максимальне зниження навантаження й глобальну швидкість».

Чого я уникаю: інколи кешувати HTML, але без чіткої політики. Це породжує сайт, який швидкий для вас і зламаний для всіх інших.

Стратегія кешування: статичне, HTML і небезпечна середина

Статичні ресурси: нудно, правильно і вигідно

Статичне кешування — це місце, де Cloudflare блищить з низьким ризиком. Якщо походження відчуває проблеми, почніть тут. Ви зменшите пропускну здатність,
знизите кількість TLS-з’єднань на вашому сервері і отримаєте плавнішу роботу під час піків трафіку.

HTML: варто, але лише з запобіжниками

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

Для більшості WordPress-сайтів безпечний бакет — «відсутні cookie залогіненого користувача і cookie сесії/корзини». Це ваш публічний кеш.
Все інше обходьте.

Небезпечна середина: кінцеві точки, що виглядають статичними, але не є такими

Це тонкі випадки:

• Сторінки пошуку: багато варіантів, інколи персоналізовані; кешування може працювати, але потрібне ретельне ключування і короткі TTL.
• Фіди: можна кешувати, але видавці ненавидять застарілі фіди; тримайте TTL коротким.
• REST API: публічні кінцеві точки можна кешувати, автентифіковані — ні.
• Локалізований або A/B контент: якщо контент змінюється за cookie або заголовком, ваш ключ кешу має його враховувати або потрібно обходити.

Якщо не впевнені — обходьте. Швидко й неправильно все одно неправильно, просто з кращими часами відповіді.

Правила «ніколи не кешувати» для wp-admin, входу та попереднього перегляду

Шляхи, що завжди мають обходити кеш

Якщо ви реалізуєте лише одну річ — реалізуйте цей список. Його можна перенести в Cloudflare Cache Rules (рекомендовано), старі Page
Rules (legacy) або Worker.

• *example.com/wp-admin/* → Bypass cache
• *example.com/wp-login.php* → Bypass cache
• *example.com/wp-admin/admin-ajax.php* → Bypass cache
• *example.com/wp-cron.php* → Bypass cache (або обмежити; не кешувати)
• *example.com/?preview=true* → Bypass cache
• *example.com/*preview_id=* and *preview_nonce=*Bypass cache

Вимкніть «фічі продуктивності» для адмін-шляхів

Деякі оптимізації чудові для анонімного трафіку і дратують автентифікованих користувачів. Для адмін-шляхів і шляхів входу
я надаю перевагу нудному вибору:

• Вимкніть мінімізацію HTML, якщо вона коли-небудь ламала ваш адмін UI (таке трапляється з дивними плагінами).
• Будьте обережні з Rocket Loader-подібним переписуванням JS. Адмін завантажує багато скриптів; вам там не потрібна магія краю.
• Тримайте функції безпеки (WAF) увімкненими, але протестуйте, щоб вони не ставили виклики адміністраторам під час дій.

Кешування з урахуванням cookie: ваш реальний контрольний шар

Правила по шляхах забезпечують безпеку wp-admin. Правила по cookie тримають у безпеці все інше. Більшість постів «Cloudflare зламав мій WordPress»
насправді означають «ми кешували HTML, ігноруючи cookie, що змінюють контент».

Сигнали cookie, при наявності яких слід обходити кеш

Мінімум:

• wordpress_logged_in_*
• wordpress_sec_*
• wp-postpass_*

Додайте якщо є:

• Cookie плагінів членства або LMS (специфічні для плагіна)
• Cookie селектора мови, якщо сайт змінює контент за cookie
• Cookie A/B-тестів, якщо вони змінюють HTML

А як щодо cookie «автора коментаря»?

WordPress встановлює cookie на кшталт comment_author_* після коментування. Вони часто не змінюють суттєво вивід сторінки для більшості сайтів.
Якщо ви кешуєте HTML і бачите дивну поведінку для нещодавніх коментаторів, обходьте також за цими cookie. Якщо ви оптимізуєте коефіцієнт попадань,
тестуйте спочатку; не наслідуйте бездумно.

Дисципліна ключа кешу: не варіюйте за кожною cookie

Варіювання кешу за кожною cookie руйнує коефіцієнт попадань і може збільшити використання сховища кешу. Хитрість у тому, щоб обходити,
коли присутні станозалежні cookie, а не створювати мільйон варіантів кешу.

WooCommerce та інші сторінки з персоналізацією

WooCommerce додає сесії клієнта, стан корзини і потоки оформлення, які алергічні до некоректного кешування. Ви все ще можете
кешувати сторінки продуктів і категорій для анонімних користувачів — зазвичай з великим виграшем — але потрібно вирізати
транзакційні шляхи.

Завжди обходьте кеш для цих шляхів WooCommerce

• /cart/*
• /checkout/*
• /my-account/*
• /?wc-ajax=*
• Будь-який endpoint або query-параметр «add-to-cart», який використовує ваша тема

Обхід при наявності цих cookie WooCommerce

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_*

Що безпечно кешувати у WooCommerce

Публічні сторінки товарів, списки категорій, статичні зображення, CSS/JS. Тримайте TTL розумним (від хвилин до години), якщо у вас немає сильної інтеграції очищення при зміні запасів/цін.

Жарт #2: Якщо ви кешуєте сторінку оформлення замовлення, ви не побудували ecommerce — ви побудували інтерактивну гру вгадування.

Заголовки від походження: Cache-Control, Vary і чому це важливо

Політика кешування Cloudflare — діалог між вашим походженням, налаштуваннями Cloudflare і запитом. Якщо ви контролюєте лише одну сторону цього діалогу, ви неправильно зрозумієте результат.

Cache-Control: намір походження

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

• Cache-Control: private, no-store або no-cache залежно від вашого стеку

Для публічного HTML, який ви готові кешувати:

• Cache-Control: public, max-age=0, s-maxage=... (якщо ви хочете, щоб край кешував довше, ніж браузери)
• Або дозволити Cloudflare встановлювати Edge TTL і тримати TTL браузера помірним

Vary: тихий множник ключа кешу

Vary каже кешам, які заголовки запиту впливають на відповідь. Якщо походження відправляє Vary: Cookie,
ви фактично робите кожну комбінацію cookie окремим об’єктом. Це може бути правильним для персоналізованих відповідей, і катастрофічним для продуктивності, якщо просочиться на публічні сторінки.

Віддавайте перевагу уникненню Vary: Cookie на публічному HTML шляхом обходу на основі cookie. Якщо плагін примушує це робити,
можливо, доведеться вимкнути таку поведінку або погодитися на нижчий коефіцієнт попадань.

Цитата, на якій можна реально побудувати систему

Вернер Фогельс (ідея в парафразі): «Все ламається, постійно — проектуйте так, щоб системи продовжували працювати у будь-якому випадку.» Це стосується і кешування:
припускайте часткові відмови і застарілі об’єкти, а потім обмежуйте радіус ураження.

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

Ось перевірки, які я запускаю, коли хтось каже «Cloudflare кешування зламало wp-admin» або «ми ввімкнули кеш і тепер усе дивно».
Кожне завдання включає команду, приклад виводу, що це означає, і яке рішення приймати.

Завдання 1: Підтвердити, чи Cloudflare кешує публічну сторінку

cr0x@server:~$ curl -sI https://example.com/ | egrep -i 'cf-cache-status|cache-control|age|server'
server: cloudflare
cf-cache-status: HIT
age: 842
cache-control: max-age=0, s-maxage=3600

Значення: Відповідь обслуговується Cloudflare (server: cloudflare) і є HIT з віком об’єкта 842 секунди.

Рішення: Публічне кешування HTML активне. Далі перевірте, чи працює обхід за cookie для залогінених сесій.

Завдання 2: Перевірити, що wp-admin не кешується (має бути BYPASS або DYNAMIC)

cr0x@server:~$ curl -sI https://example.com/wp-admin/ | egrep -i 'cf-cache-status|location|set-cookie|cache-control'
cf-cache-status: DYNAMIC
cache-control: no-store, no-cache, must-revalidate, max-age=0

Значення: Cloudflare не віддав це з кешу. Походження вказує no-store/no-cache.

Рішення: Обхід по шляху для /wp-admin/ працює. Якщо адміністратори все ще мають проблеми, перевірте cookie, WAF або продуктивність походження.

Завдання 3: Перевірити, що wp-login.php не кешується

cr0x@server:~$ curl -sI https://example.com/wp-login.php | egrep -i 'cf-cache-status|cache-control|set-cookie'
cf-cache-status: DYNAMIC
cache-control: no-store, no-cache, must-revalidate, max-age=0

Значення: Вхід не кешується. Добре.

Рішення: Якщо відбуваються петлі входу, ймовірно є проблема з cookie/редиректами або налаштуваннями HTTP/HTTPS у WordPress/Cloudflare.

Завдання 4: Симулювати залогінений cookie і переконатися, що публічні сторінки обходяться

cr0x@server:~$ curl -sI https://example.com/ -H 'Cookie: wordpress_logged_in_abc=1' | egrep -i 'cf-cache-status|cache-control|age'
cf-cache-status: BYPASS
cache-control: private, no-cache, no-store, must-revalidate

Значення: Правило обходу за cookie працює; Cloudflare не кешує HTML коли існує cookie залогінення.

Рішення: Безпечно для автентифікованих користувачів. Якщо тут видно HIT, зупиніться і виправте правила, перш ніж витікне персоналізований контент.

Завдання 5: Перевірити поведінку кешування REST API (публічна кінцева точка)

cr0x@server:~$ curl -sI https://example.com/wp-json/ | egrep -i 'cf-cache-status|cache-control|content-type'
content-type: application/json; charset=UTF-8
cf-cache-status: DYNAMIC
cache-control: no-cache, must-revalidate, max-age=0

Значення: REST корінь динамічний і не кешується.

Рішення: Тримайте його динамічним, якщо немає конкретної причини кешувати деякі публічні endpoint-и з коротким TTL і чіткою стратегією інвалідизації.

Завдання 6: Виявити випадкове кешування попередніх переглядів (класична помилка)

cr0x@server:~$ curl -sI "https://example.com/?p=123&preview=true" | egrep -i 'cf-cache-status|cache-control|age'
cf-cache-status: DYNAMIC
cache-control: private, no-cache, no-store, must-revalidate

Значення: Відповіді попереднього перегляду не кешуються.

Рішення: Якщо тут HIT, додайте правила обходу для параметрів попереднього перегляду негайно.

Завдання 7: Підтвердити, що admin-ajax не кешується

cr0x@server:~$ curl -sI https://example.com/wp-admin/admin-ajax.php | egrep -i 'cf-cache-status|cache-control'
cf-cache-status: DYNAMIC
cache-control: no-store, no-cache, must-revalidate, max-age=0

Значення: Добре. Кешування admin-ajax ламає випадкові частини адмін-інтерфейсу і фронтенд-функцій.

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

Завдання 8: Перевірити cookie WordPress зі сторінки входу

cr0x@server:~$ curl -sI https://example.com/wp-login.php | egrep -i 'set-cookie|location'
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly; SameSite=Lax

Значення: WordPress встановлює тестовий cookie; процес входу залежить від прийняття cookie.

Рішення: Якщо cookie відсутні або змінені, перевірте Cloudflare Transform Rules/Workers, заголовки безпеки або плагін, що втручається в cookie.

Завдання 9: Перевірити коректність HTTPS і ланцюжок редиректів

cr0x@server:~$ curl -sI http://example.com/wp-admin/ | egrep -i 'HTTP/|location|server'
HTTP/1.1 301 Moved Permanently
server: cloudflare
location: https://example.com/wp-admin/

Значення: HTTP коректно редиректить на HTTPS.

Рішення: Якщо ви бачите петлі (http→https→http), виправте режим SSL (звичайно Full/Strict) і переконайтеся, що WordPress “Site URL” і “Home” — з HTTPS.

Завдання 10: Перевірити, чи Cloudflare віддає кешований HTML запиту з cookie WooCommerce

cr0x@server:~$ curl -sI https://example.com/product/widget/ -H 'Cookie: wp_woocommerce_session_123=1; woocommerce_items_in_cart=1' | egrep -i 'cf-cache-status|age'
cf-cache-status: BYPASS

Значення: Правильна поведінка: не кешувати HTML із станом сесії/корзини WooCommerce.

Рішення: Якщо бачите HIT, додайте правила обходу за cookie і обходьте транзакційні шляхи негайно.

Завдання 11: Підтвердити заголовки відповіді від походження напряму (обхід Cloudflare)

cr0x@server:~$ curl -sI https://origin.example.internal/ | egrep -i 'cache-control|vary|set-cookie|server'
server: nginx
cache-control: public, max-age=0, s-maxage=600
vary: Accept-Encoding

Значення: Походження має на увазі кешування на краю на 600 секунд і не варіює за Cookie. Це добре для публічних сторінок.

Рішення: Узгодьте Edge TTL у Cloudflare з наміром походження або переопишіть обережно. Якщо бачите Vary: Cookie, очікуйте проблем з коефіцієнтом попадань.

Завдання 12: Перевірити несподівані cookie у анонімних запитах

cr0x@server:~$ curl -sI https://example.com/ | egrep -i 'set-cookie'
set-cookie: pll_language=en; path=/; secure; SameSite=Lax

Значення: Плагін мови встановлює cookie навіть для анонімних користувачів. Це може або не може змінювати HTML.

Рішення: Якщо контент залежить від цього cookie, або варіюйте кеш за ним (обережно), або обходьте для таких користувачів; в іншому випадку ігноруйте його, щоб зберегти високий коефіцієнт попадань.

Завдання 13: Підтвердити, що очищення справді змінює об’єкт (виявити застарілий контент)

cr0x@server:~$ curl -sI https://example.com/ | egrep -i 'cf-cache-status|age|etag|last-modified'
cf-cache-status: HIT
age: 3599
etag: "a1b2c3"

Значення: Об’єкт на краю майже годину старий.

Рішення: Якщо ви щойно оновили контент і очікували змін — вам потрібно або (a) кращі тригери очищення, (b) коротший TTL для HTML, або (c) cache-busting через surrogate keys/tags (якщо ваша система це підтримує).

Завдання 14: Перевірити здоров’я походження і затримки коли кеш обходиться

cr0x@server:~$ curl -s -o /dev/null -w 'ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/wp-admin/
ttfb=1.842 total=1.913

Значення: Time-to-first-byte ≈ 1.8s для адмінки. Це час походження/PHP/DB, а не Cloudflare.

Рішення: Перестаньте одержувати одержимість краєм і профілюйте PHP-воркерів, запити до БД та object cache. Адмінка в основному залежить від походження.

Завдання 15: Переглянути навантаження PHP-FPM (поширена причина повільної адмінки)

cr0x@server:~$ sudo ss -s
Total: 256 (kernel 0)
TCP:   128 (estab 22, closed 84, orphaned 0, synrecv 0, timewait 84/0), ports 0

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  6         4         2
TCP	  44        28        16
INET	  50        32        18
FRAG	  0         0         0

Значення: Це безпосередньо не показує PHP-FPM, але демонструє знос з’єднань. Поєднайте з статусом PHP-FPM або кількістю процесів.

Рішення: Якщо адмін повільний під час високого трафіку і шляхи обхід кешу переповнені, збільшіть потужність PHP-FPM або зменшіть важкі адмін-плагіни замість підстроювання TTL на краю.

Завдання 16: Перевірити журнали доступу Nginx на предмет інтенсивних звернень до шляхів обходу кешу

cr0x@server:~$ sudo tail -n 5 /var/log/nginx/access.log
203.0.113.10 - - [27/Dec/2025:10:14:01 +0000] "POST /wp-login.php HTTP/2.0" 200 4578 "-" "Mozilla/5.0"
203.0.113.11 - - [27/Dec/2025:10:14:02 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"
203.0.113.12 - - [27/Dec/2025:10:14:02 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"
203.0.113.13 - - [27/Dec/2025:10:14:03 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"
203.0.113.14 - - [27/Dec/2025:10:14:03 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"

Значення: Виклики heartbeat можуть накопичуватись при багатьох редакторах і збільшувати навантаження на PHP. Кешування тут не допоможе, бо його не слід кешувати.

Рішення: Налаштуйте частоту Heartbeat, зменшіть одночасну кількість редакторів або масштабируйте PHP-воркери. Розгляньте обмеження частоти зловмисних патернів на краю.

План швидкої діагностики

Коли ви відповідальні і хтось кричить «Cloudflare винен», потрібен короткий шлях до істини. Ось мій потік перевірок: перевірте-перше/друге/третє.

Перше: чи кешована погана відповідь?

• Перевірте CF-Cache-Status на проблемному URL.
• Якщо це HIT або STALE на адмін/вхід/попередньому перегляді — ви вже знайшли проблему: ваші правила обходу неправильні.
• Якщо це DYNAMIC або BYPASS, кеш Cloudflare, ймовірно, не є прямою причиною. Рухайтесь далі.

Друге: чи запит станозалежний (cookie) і ви забули обхід?

• Повторіть запит з симульованим cookie wordpress_logged_in_* і впевніться, що він обходиться.
• Для WooCommerce — тестуйте з cookie корзини/сесії.
• Якщо запити з cookie кешуються — зупиніться. Виправте обхід cookie і очистіть уражені HTML.

Третє: чи це mismatch редиректів/режиму SSL?

• Перевірте ланцюг редиректів від HTTP до HTTPS і нормалізацію www/апексу (або навпаки).
• Підтвердіть, що WordPress “Home URL” і “Site URL” відповідають тому, що подає Cloudflare.
• Режим SSL Cloudflare має бути Full (Strict), якщо на походженні є дійсний сертифікат.

Четверте: чи це насправді продуктивність походження?

• Виміряйте TTFB для /wp-admin/ та інших шляхів, що обходять кеш.
• Якщо TTFB високий, оптимізуйте PHP/БД/object cache. Адмінка ніколи не стане швидкою, якщо походження «тає».

П’яте: чи це функція безпеки, що заважає (WAF / bot fight / challenges)?

• Шукайте 403/429/JS challenges під час адмін-дій.
• Додайте у білл-лист офісні IP або вимагайте SSO/VPN для адмінки замість відключення захисту глобально.

Поширені помилки: симптом → причина → виправлення

1) Симптом: wp-admin показує кешований «Будь ласка, увійдіть», навіть після входу

Причина: /wp-admin/ або /wp-login.php були закешовані через «Cache Everything» без обходу.

Виправлення: Додайте явні правила обходу для /wp-admin/*, /wp-login.php і очистіть кеш. Перевірте з CF-Cache-Status: DYNAMIC.

2) Симптом: цикл редиректу при вході (wp-login.php → wp-admin → wp-login.php)

Причина: Змішана схема (HTTP/HTTPS) або неправильний режим SSL; cookie встановлюються для HTTPS, але запити ходять через HTTP, або походження думає, що воно HTTP за проксі.

Виправлення: Переконайтеся, що Cloudflare у режимі Full (Strict) до походження, примусьте HTTPS, встановіть URL-адреси WordPress з HTTPS і переконайтеся, що походження бачить правильні X-Forwarded-Proto / CF-Visitor.

3) Симптом: попередній перегляд показує старий контент або чужу чернетку

Причина: URL попереднього перегляду були кешовані на краю. Параметри попереднього перегляду не виключені.

Виправлення: Обходьте кеш для preview=true, preview_id, preview_nonce і подумайте про повний обхід для залогінених cookie.

4) Симптом: корзина WooCommerce показує неправильні товари або раптово пуста

Причина: Сторінки корзини/оформлення кешуються або кешуються фрагменти. Або відсутній обхід за cookie.

Виправлення: Обходьте кеш для шляхів cart/checkout/my-account, обходьте за cookie сесії/корзини WooCommerce і не кешуйте ?wc-ajax=*.

5) Симптом: залогінені користувачі бачать відсутню або напівзламану панель адміністратора

Причина: HTML кешовано для залогінених користувачів, або оптимізації на краю переписують JS/CSS у wp-admin/фронтенді для автентифікованих сесій.

Виправлення: Обходьте HTML для wordpress_logged_in_*. Вимкніть ризикові оптимізації скриптів на адмін/вхід шляхах.

6) Симптом: випадкові 403 у wp-admin, особливо при збереженні/публікації

Причина: WAF правило підходить під адмін POSTs, або захист від ботів кидає виклики під час автентифікованих дій.

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

7) Симптом: сайт швидкий для анонімних користувачів, але wp-admin надзвичайно повільний

Причина: Це нормально, якщо походження перевантажене. Адмінку не можна безпечно кешувати, тому вона відкриває проблеми з PHP/БД.

Виправлення: Додайте object cache, налаштуйте PHP-FPM, зменшіть важкі адмін-плагіни, оптимізуйте БД і розгляньте масштабування походження. Не намагайтеся «кешувати wp-admin».

8) Симптом: очищення «виправляє», але лише на кілька хвилин

Причина: Ви маскуєте неправильну політику кешування; контент кешується тоді, коли не повинен, або TTL надто довгий без інтеграції очищення.

Виправлення: Виправте правила обходу, скоригуйте TTL і реалізуйте таргетовані очищення при публікації/оновленнях. Очищення як спосіб виживання — не стратегія.

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

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

Середня компанія розмістила маркетинговий сайт WordPress за Cloudflare. Доброзичливий інженер побачив високий CPU на походженні під час кампанії
і ввімкнув «Cache Everything» для всієї зони, вирішивши, що WordPress «знає», коли не кешувати адмін-сторінки.
Він спирався на те, що заголовки Cache-Control походження їх деесь врятують.

Протягом години все виглядало чудово — TTFB впав, навантаження на походження вирівнялося, дашборди були в захваті. Потім редактори почали скаржитися,
що їх «випадково викидає з сесії». За кілька хвилин з’явилось повідомлення, що wp-admin іноді показує стан іншої людини. На щастя, не було витоку контенту, але паніка почалась.

Корінь проблеми був буденний: одне широке правило застосували до /* без явного обходу для /wp-admin/
і /wp-login.php. Деякі адмін-відповіді мали кешовані коди стану і були закешовані достатньо довго, щоб створити карусель плутанини.
Походження інколи відправляло «no-store», але не послідовно для всіх випадків і редиректів у процесі входу.

Виправлення теж буденне: явні правила обходу для адмінки/входу плюс обхід за cookie залогінених сесій. Потім повне очищення HTML.
Довгострокове виправлення — культурне: жодна зміна кешування без швидкої curl-перевірки CF-Cache-Status для адмінки, входу, попереднього перегляду і запиту з cookie.

Історія 2: Оптимізація, що обернулася проти

Велика організація хотіла «глобальної паритетної швидкості» і вирішила кешувати публічний HTML на краю з довгим TTL, щоб зменшити витрати на походження.
Вони налаштували заплановане очищення щогодини «на всякий випадок». Це виглядало розумно в електронній таблиці.

У продакшні щогодинне очищення створювало передбачувану лавину навантаження на походження. Після очищення коефіцієнт попадань розвалювався,
кожна сторінка була MISS, походження отримувало шквал запитів. Балансувальник навантаження почав чергувати, PHP-воркери наситились, і wp-admin став непридатним для редакторів саме в ті періоди, коли команда контенту була найактивнішою.

До того ж, декілька сторінок були персоналізовані плагіном згоди, який інжектував трохи відмінний HTML залежно від cookie. Ключ кешу не враховував цей cookie
(оскільки варіювання за cookie зруйнувало б коефіцієнт попадань), тому після кожного очищення перший закешований варіант «вигравав лотерею» і обслуговувався іншим користувачам, поки не протухне.

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

Урок: якщо ваш кеш вимагає частого повного очищення, політика кешу неправильно налаштована. Вам не потрібна більша кнопка «очистити». Вам потрібно менше причин її натискати.

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

Інша команда мала сувору політику «зміни з доказом». Кожна зміна кешування Cloudflare вимагала запуску маленького тестового скрипта з бастіону:
отримати публічну сторінку, wp-admin, wp-login, URL попереднього перегляду, домашню сторінку з симульованим cookie залогіненого і записати ключові заголовки.

Це здавалося повільним, особливо коли продуктова команда хотіла миттєвих виграшів у продуктивності. Але команда мала шрами. Вони бачили витоки стану кешем раніше і віддавали перевагу нудному перед драматичним.

Одної п’ятниці запропонували оптимізацію: кешувати HTML на краю для набору маркетингових лендингів. Інженер запустив скрипт і помітив дивину: лендинги ставили cookie від інструменту маркетингової автоматизації при першому перегляді, і HTML тонко змінювався, додаючи персоналізований трекінговий піксель.

Оскільки cookie був у багатьох користувачів, кеш віддав би варіант «cookie-присутній» анонімним користувачам і навпаки, і маркетинг звинуватив би аналітику у «нестабільності». Натомість вони кешували лише статичні ресурси на краю і тримали HTML консервативним, поки не переробили скрипти лендингу.

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

Чеклісти / покроковий план

Покроково: безпечна конфігурація кешу Cloudflare для WordPress

1. Почніть лише зі статичних ресурсів.
   • Встановіть довгий Edge TTL і Browser TTL для версіонованих ресурсів.
   • Перевірте CF-Cache-Status: HIT для .css, .js, зображень.
2. Встановіть обов’язкові правила обходу.
   • Обходьте /wp-admin/*, /wp-login.php, /wp-admin/admin-ajax.php, параметри попереднього перегляду.
   • Переконайтесь, що вони показують CF-Cache-Status: DYNAMIC або BYPASS.
3. Додайте обхід за cookie для автентифікованих і станозалежних сесій.
   • Обходьте при збігу cookie wordpress_logged_in_*, wordpress_sec_*, wp-postpass_*.
   • Якщо ecommerce: обходьте cookie WooCommerce та шляхи корзини/оформлення.
4. Якщо кешуєте HTML на краю — робіть це явно і вузько.
   • Кешуйте публічний HTML лише коли відсутні state cookie.
   • Встановіть розумний TTL (почніть з 5–15 хвилин) і коригуйте після спостережень за частотою оновлень контенту.
5. Визначте політику очищення.
   • Віддавайте перевагу таргетованим очищенням при публікації/оновленні.
   • Уникайте запланованих повних очищень сайту, якщо не любите лавини на походженні.
6. Тестуйте реальними потоками.
   • Увійдіть, відредагуйте, перегляньте, опублікуйте, завантажте медіа, оновіть меню.
   • Переконайтеся, що адмін-ендпоїнти не кешуються і немає застарілого попереднього перегляду.
7. Спостерігайте і ітеруйте.
   • Відстежуйте коефіцієнт попадань, TTFB походження і кількість помилок.
   • Будь-який новий плагін, що встановлює cookie, стає елементом перевірки кешу.

Операційний чекліст: до і після будь-якої зміни кешування

• Підтвердьте, що /wp-admin/ не кешується.
• Підтвердьте, що /wp-login.php не кешується.
• Підтвердьте, що URL попереднього перегляду не кешуються.
• Підтвердьте, що домашня сторінка кешується для анонімних запитів (якщо ви плануєте кешувати HTML).
• Підтвердьте, що домашня сторінка обходиться при наявності cookie wordpress_logged_in_*.
• Підтвердьте обхід корзини/оформлення WooCommerce (якщо застосовно).
• Підтвердьте правильний ланцюг редиректів (HTTP→HTTPS, нормалізація www).
• Підтвердьте, що під час адмін-дій немає WAF-викликів.
• Занотуйте заголовки до/після: CF-Cache-Status, Cache-Control, Vary.
• Майте план відкату: вимкнути кешування HTML, очистити HTML, зберегти статичне кешування.

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

1) Чи можна кешувати wp-admin, щоб зробити його швидшим?

Ні, безпечно — не можна. wp-admin автентифікований, насичений nonce і специфічний для користувача. Робіть його швидшим, оптимізуючи PHP/БД/object cache і зменшуючи навантаження адмін-плагінів.
Кешуйте статичні ресурси глобально; залишайте адмінку динамічною.

2) Чи «Cache Everything» завжди погано для WordPress?

Не завжди. Це небезпечно, коли застосовується широко без жорстких правил обходу. Якщо ви поєднаєте його з обходом для адмінки/входу/попереднього перегляду і обхід за cookie для станозалежних сесій, воно може працювати добре для публічного контенту.

3) Який мінімальний список cookie для обходу у WordPress?

wordpress_logged_in_*, wordpress_sec_* і wp-postpass_*. Потім додайте cookie WooCommerce або cookie плагінів членства за потреби.

4) Чому саме попередні перегляди ламаються?

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

5) Чи потрібно обходити /wp-json/?

Для автентифікованих запитів — так. Для публічних кінцевих точок — залежить. Якщо немає явної користі і плану з коротким TTL, тримайте їх динамічними. Кешування REST легко зробити непомітно неправильним.

6) Мій сайт ставить багато cookie для анонімних користувачів. Чи означає це, що я не можу кешувати HTML?

Не обов’язково. Питання в тому, чи змінюється HTML через ці cookie. Якщо так — перемістіть персоналізацію на клієнт або варіюйте кеш обережно по вузькому набору cookie. Якщо ні — ігноруйте їх для рішень щодо кешу.

7) Чому мій коефіцієнт попадань низький, хоча я ввімкнув кеш?

Поширені причини: ви варіюєте за забагатьма речами (заголовки/cookie), TTL надто короткий, query string створює багато варіантів, або ви занадто часто очищуєте. Вимірюйте CF-Cache-Status для топових URL і зменшуйте непотрібну варіативність.

8) Чи покладатися на заголовок Cache-Control походження або на Edge TTL у Cloudflare?

Ідеально — обидва мають бути узгоджені. На практиці я віддаю перевагу явним правилам Cloudflare щодо того, що і на який час кешувати, а потім тримаю заголовки походження в адекватному стані: «no-store» для адмінки/персоналізованого, розумні підказки кешу для публічного контенту. Тестуйте результат, не сперечайтесь.

9) Чи потрібно очищати на кожному оновленні посту?

Якщо ви кешуєте HTML на краю і редактори очікують миттєвих змін — так, принаймні для уражених сторінок (URL посту, домашня, сторінки категорій). Якщо можете терпіти коротку затримку — встановіть коротший TTL і очищайте рідше. Оберіть одне: простоту операцій або миттєву свіжість.

10) Який найбезпечніший перший виграш у продуктивності, що не зачіпає wp-admin?

Кешуйте статичні ресурси на краю з довгими TTL, увімкніть стиснення і оптимізуйте походження PHP/БД для адмінки. Це дає видимий приріст швидкості без ризику для автентифікованих потоків.

Висновок: подальші кроки, що працюють

Cloudflare кешування не «ламає wp-admin». Люди ламають wp-admin, кешуючи те, що ніколи не слід кешувати, а потім припускають, що край магічно виведе стан користувача з атмосфери.
Виправлення — механічне: виріжте адмінку/вхід/попередній перегляд, обходьте за state cookie і ставтеся до кешування HTML як до контрольованої функції з тестами.

Практичні подальші кроки:

1. Запустіть перевірки заголовків для головної сторінки, wp-admin, wp-login і URL попереднього перегляду. Зафіксуйте CF-Cache-Status.
2. Реалізуйте правила обходу по шляхах для адмінки/входу/admin-ajax і параметрів попереднього перегляду. Верифікуйте одразу за допомогою curl.
3. Додайте обхід за cookie для cookie автентифікації WordPress і cookie ecommerce/сесій.
4. Якщо кешуєте HTML, почніть з короткого TTL і таргетованих очищень при публікації. Ніколи не робіть заплановані повні очищення стилем життя.
5. Коли wp-admin повільний — перестаньте звинувачувати кеш і виміряйте TTFB походження. Потім налаштуйте PHP-FPM і базу даних як дорослі.