Від правки на годинудо магазину з нуля.

Клієнт сформулював це так: жива CRM далека від прототипу, по всіх сторінках і блоках. У кімнаті очікували переписування з нуля.

Компоненти були правильні. Неправильним був порядок стилів: дизайн-кіт підключався перед Tailwind, тому preflight обнуляв усі заголовки, а один клас на body перебивав шрифт кіта. Дві структурні правки повернули більшість екранів на місце й звели реальну різницю до обсягу робіт.

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

Близько 15% запитів віддавали HTTP 500 — 825 з них за півтори години спостереження. Кількість подвоювалась щотижня: 17 фатальних помилок 4 серпня, 413 — 18-го, 915 — 21-го. Хостер вказав на ліміт з’єднань і на цьому зупинився.

Кожна фатальна помилка була одним і тим самим рядком: з’єднання з базою всередині обробника сесій. Хостер підтвердив, що акаунт упирається у стелю в 30 одночасних з’єднань.

Таблиця сесій містила 18 715 802 рядки й 2 284 МБ — 89% усієї бази. Сесії з 2023 року досі лежали в ній.

Кожен запит, включно з кожним ботом, пише в цю таблицю. На 2,3 ГБ кожен запис тримає з’єднання достатньо довго, щоб тридцять із них наклались. Сам сервер був здоровий: 40 ядер під навантаженням 40%, вільних 67 ГБ RAM. Сусіди по шареду ні до чого.

OpenCart 3 порівнює int із колонкою datetime у збирачі сміття сесій, тому запит на чистку не збігався ніколи — жодного разу за три роки. Сесії просто накопичувались, доки ліміт з’єднань не зробив решту.

База даних: 2 562 МБ → 301 МБ. Таблиця сесій: 2 284 МБ → 22 МБ. Головна сторінка: 370 мс → 116 мс. 22 839 142 рядки видалено за 17 хвилин, порціями по 5 000 з паузою між ними — load average сервера під час чистки не виріс, а впав.

Ззовні все було гаразд. Відвідувачі бачили справжній магазин. Так само його бачили curl, PageSpeed, Ahrefs, монітор аптайму й кожен сканер, який пробував власник. А тим часом головну переіндексовували як турецьку гемблінг-сторінку — з canonical, що вказував назад на домен клієнта.

Клоак мав список декой-юзерагентів — curl, wget, python, ahrefsbot, semrushbot, lighthouse, pagespeed, gtmetrix, uptimerobot, gptbot — і для кожного з них вимикався. Саме тому жодна перевірка нічого не знаходила.

index.php показував час зміни серпня 2025 року, а ctime — 1 вересня 2026-го. Зловмисник повернув mtime через touch; ctime без root підробити неможливо. Саме ця розбіжність і видала файл — пошук за датою модифікації пройшов би повз.

Закріплень було два, а не одне: інжект у index.php і .user.ini з auto_prepend_file, який PHP підвантажує до кожного запиту в теці незалежно від того, що написано в index.php.

Лог доступу назвав причину точно. Контролер теми виконував unserialize(base64_decode($_POST[…])) — PHP object injection, у файлі від 2022 року, який ніколи не патчили. Сканер перебрав відомі вразливі ендпоінти чужих тем OpenCart, зібрав по 404 з кожного, влучив у цей — і мав веб-шел через 24 секунди після першого запиту. Той самий рядок був у п’яти місцях, і одне з них перекривала ocmod-збірка: правка лише оригіналу залишила б найнавантаженіший ендпоінт відчиненим.

Перевірено ззовні: до чистки Googlebot отримував сторінку казино, після — справжній титул магазину й жодної згадки чужого бренду. Усі п’ять точок входу закрито, чотири закладки видалено, очищений файл вийшов байт у байт ідентичним еталону — підтверджено двома незалежними способами. Кнопка «показати ще» на сайті працює як працювала.

Акаунт розрісся до 35 ГБ із 48 і продовжував рости. Очевидний хід — купити більший тариф.

Росли не оригінали товарних фото: 18 → 19 ГБ за чотири дні. Кеш мініатюр за той самий час пішов з 8,8 до 16 ГБ.

Стокова бібліотека зображень OpenCart пише JPEG-мініатюри якістю 90 і взагалі не стискає PNG. Тобто кеш був не наслідком великої кількості товарів — його виробляв сам движок, щоразу коли в нього просили новий розмір.

Стиснути наявне означало купити кілька тижнів. Движок мусив перестати це виробляти — невелика правка бібліотеки зображень плюс один прохід по тому, що вже лежить на диску.

Оброблено 74 649 оригіналів і близько 83 000 мініатюр — з обмеженням якості, ніколи не збільшуючи файл, без зміни форматів і без дотику до бази. 794 файли перевірено на цілісність, зіпсованих нуль. Оригінали: 30 264 МБ → 18 281 МБ. Кеш мініатюр: 16 ГБ → 8,2 ГБ.