У цій статті я поділюся нашим досвідом вирішення двох складних проблем на сервері з CyberPanel та OpenLiteSpeed: повільна робота адмінок WordPress і недоступність WebAdmin OpenLiteSpeed на порту 7080. Цей кейс буде корисним для адміністраторів серверів, веб-розробників і власників сайтів на WordPress, які стикаються з подібними проблемами. Ми пройдемо весь шлях — від діагностики до оптимізації — з усіма командами, поясненнями та висновками.
На сервері з CyberPanel, який розміщений на Digital Ocean (дроплет із 1 ГБ RAM, 8 CPU), я помітив, що:
http://[SERVER_IP]:7080 не відкривається в браузері.lsphp), середнє навантаження (load average) перевищує 10 при 8 CPU, а свап-пам’ять активно використовується (400 МБ із 981 МБ).Домен [olddomain.com], який раніше використовувався для WebAdmin, був видалений, і сертифікати Let’s Encrypt для нього прострочені (з червня 2022 року), що спричинило проблеми з HTTPS-доступом.
Першою проблемою була недоступність WebAdmin OpenLiteSpeed на http://[SERVER_IP]:7080. Я почав із перевірки.
Я виконав команду, щоб перевірити, чи порт 7080 слухає:
ss -tuln | grep 7080
Результат:
udp UNCONN 0 0 0.0.0.0:7080 0.0.0.0:* tcp LISTEN 0 4096 0.0.0.0:7080 0.0.0.0:*
Порт слухає, тобто OpenLiteSpeed теоретично має відповідати.
curl із сервераЯ виконав:
curl -v http://[SERVER_IP]:7080
Результат:
* Connected to [SERVER_IP] ([SERVER_IP]) port 7080 (#0) > GET / HTTP/1.1 > Host: [SERVER_IP]:7080 < HTTP/1.1 302 Found < location: /login.php < server: LiteSpeed
WebAdmin працює і перенаправляє на /login.php, що є нормальною поведінкою. Але в браузері сторінка не відкривалася.
Я помітив, що в конфігурації WebAdmin (/usr/local/lsws/admin/conf/admin_config.conf) було вказано secure 1, що змушувало сервер перенаправляти запити з HTTP на HTTPS. Однак сертифікати для [olddomain.com] були прострочені, тому HTTPS (https://[SERVER_IP]:7080) не працював.
Я спробував змінити secure 1 на secure 0, щоб відключити HTTPS:
sed -i 's/secure 1/secure 0/' /usr/local/lsws/admin/conf/admin_config.conf systemctl restart lsws
Але це не спрацювало одразу через проблеми із синтаксисом команди sed (наприклад, зайві пробіли в рядку). Я відредагував файл вручну:
nano /usr/local/lsws/admin/conf/admin_config.conf
Змінив secure 1 на secure 0 і перезапустив OpenLiteSpeed:
systemctl restart lsws
Після відключення HTTPS я знову виконав curl із сервера, і WebAdmin відповідав коректно. Але з локального комп’ютера (Mac) сторінка не відкривалася:
curl -v http://[SERVER_IP]:7080 * connect to [SERVER_IP] port 7080 failed: Operation timed out
Це вказувало на проблему із зовнішнім доступом. Я перевірив брандмауер ufw:
ufw status
Результат: Status: inactive. Я увімкнув ufw і додав правило:
ufw enable ufw allow 7080/tcp ufw allow 22/tcp # Щоб не втратити доступ через SSH ufw reload
Але це не допомогло. Я зрозумів, що проблема може бути в брандмауері CyberPanel.
CyberPanel має власний брандмауер, який перекриває ufw. Я увійшов у CyberPanel (https://[SERVER_IP]:8090), перейшов до Security > Firewall і додав правило:
Натиснув Reload, і після цього сторінка http://[SERVER_IP]:7080 нарешті відкрилася в браузері!
Тепер, коли доступ до WebAdmin відновлено, я перейшов до проблеми з повільною роботою адмінок WordPress. Я виконав команду top, щоб оцінити навантаження:
top - 02:14:51 up 50 min, 2 users, load average: 10.74, 9.72, 7.32
Tasks: 156 total, 17 running, 139 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.6 us, 24.3 sy, 67.1 ni, 0.0 id, 0.0 wa, 0.0 hi, 2.0 si, 0.0 st
MiB Mem : 1971.5 total, 136.0 free, 1178.2 used, 657.4 buff/cache
MiB Swap: 981.0 total, 580.2 free, 400.8 used. 208.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
766 mysql 20 0 1249868 185152 7184 S 6.0 9.2 2:31.40 mysqld
5113 user1 21 1 288064 169700 104132 R 5.3 8.4 0:02.95 lsphp
5125 user1 21 1 277740 158344 103012 R 5.3 7.8 0:02.44 lsphp
5152 user2 21 1 348492 155904 104484 R 5.3 7.7 0:01.27 lsphp
lsphp-процесів, кожен із них використовує 5–8% CPU і 7–8% пам’яті.Я увійшов у WebAdmin OpenLiteSpeed (http://[SERVER_IP]:7080) і перевірив налаштування PHP:
PHP_LSAPI_CHILDREN=10LSAPI_AVOID_FORK=200MPHP_LSAPI_CHILDREN=8
LSAPI_AVOID_FORK=300M
Я створив файл phpinfo.php, щоб перевірити статус OPcache:
/home/[example.com]/public_html:echo '<?php phpinfo();' > phpinfo.php
Але спочатку я отримав помилку:
Parse error: syntax error, unexpected '' > phpinfo.php' (T_ENCAPSED_AND_WHITESPACE), expecting end of file in /home/[example.com]/public_html/phpinfo.php on line 1
Це сталося через зайві символи у файлі. Я відредагував файл через Sublime Text (за допомогою FileZilla), залишивши лише:
<?php phpinfo();
Після цього сторінка https://[example.com]/phpinfo.php відкрилася, і я побачив:
opcache.enable = On.Я оптимізував налаштування OPcache у файлі /usr/local/lsws/lsphp74/etc/php.ini:
[opcache] opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.file_cache_consistency_checks=0
Перезапустив OpenLiteSpeed:
systemctl restart lsws
Я увійшов у WordPress-адмінку (https://[example.com]/wp-admin) і налаштував плагін LiteSpeed Cache:
Після оптимізації сторінка http://[SERVER_IP]:7080 знову стала недоступною. Я виконав curl із сервера:
* Connected to [SERVER_IP] ([SERVER_IP]) port 7080 (#0) > GET / HTTP/1.1 < HTTP/1.1 302 Found < location: /login.php
WebAdmin працював, але з локального комп’ютера доступу не було. Я ще раз перевірив CyberPanel Firewall, iptables, ufw і Digital Ocean Firewall. Виявилося, що після перезавантаження CyberPanel скинув правила. Я додав порт 7080 ще раз і переконався, що він залишиться дозволеним.
http://[SERVER_IP]:7080 відновлено після повторного налаштування брандмауера CyberPanel.curl і статус портів через ss.ufw, а й вбудований брандмауер.lsphp-процесів через PHP_LSAPI_CHILDREN (8 для 8 CPU).Сподіваюся, цей кейс допоможе вам вирішити подібні проблеми! Якщо у вас є питання, пишіть у коментарях на. 😊