Pada 22 Oktober 2026, setelah rilis patch keamanan runtime PHP, admin VPS milik klien multi-site memperbarui PHP 8.3.x ke 8.3.36 di aaPanel. Dalam jendela pemeliharaan yang sama tim ops turut memperbarui Apache, Nginx, dan Redis, lalu merestart layanan web terkait. Beberapa menit kemudian browser menampilkan 421 Misdirected Request dengan pesan ketidakcocokan SNI. Panduan ini merangkum cara update PHP di aaPanel yang aman: inventaris, backup, langkah panel, verifikasi FPM, serta diagnosis bila stack HTTPS ikut berubah. Patch interpreter tetap wajib, namun mengubah beberapa komponen sekaligus memaksa Anda memisahkan lapisan PHP dari lapisan proxy TLS.
Hostname produksi disamarkan menjadi website-a.example dan website-b.example. Output CLI di bawah ini adalah ringkasan sesi pemeliharaan partner, bukan transkrip mentah. Pengujian ulang seluruh domain di server belum tercatat setelah perbaikan. Anda perlu menyesuaikan setiap perintah dengan topology VPS sendiri.
- Patch minor PHP (misalnya 8.3.x ke 8.3.36) berbeda dari migrasi branch 8.2 ke 8.3: risiko kompatibilitas dan skenario uji tidak identik.
- aaPanel mengelola binary PHP sendiri: hindari mengganti instalasi panel dengan
apt install phptanpa prosedur integrasi resmi. - Setelah patch, yang harus dipastikan adalah proses PHP-FPM memakai binary baru, bukan reboot VPS otomatis.
- HTTP 421 setelah update Apache/Nginx kerap berkaitan dengan SNI pada proxy HTTPS ke backend, bukan bug PHP.
curl -Ilewat Cloudflare yang mengembalikan 200 tidak menggantikan uji origin dan browser untuk setiap vhost.
Mengapa runtime PHP perlu patch sebelum langkah panel?
Update PHP memperbaiki bug dan kerentanan di interpreter, berbeda dari memperbarui WordPress atau plugin. Lantaran urgensi patch Oktober 2026, artikel berita patch keamanan PHP RCE kritis Oktober 2026 layak dibaca sebagai konteks. Tutorial ini tidak menggandakan daftar CVE: fokusnya prosedur operasional dan pengujian.
Versi patch seperti 8.3.36 tidak selalu muncul bersamaan di semua mirror atau build aaPanel. Sebelum menekan tombol update, catat versi terpasang di App Store dan bandingkan dengan catatan rilis PHP resmi. Meski patch minor hanya mengganti binary patch level, migrasi major (8.2 ke 8.3) tetap menuntut uji plugin, theme, dan cron terpisah.
Persiapan inventaris dan backup sebelum update
Jadi, mulailah dengan peta stack, bukan langsung membuka PHP Manager. Catat versi PHP aktif per website (aaPanel mendukung beberapa versi sekaligus), versi Apache dan Nginx, Redis bila dipakai, pool PHP-FPM, domain, routing proxy, serta apakah traffic melewati Cloudflare. Ternyata versi dari php -v di SSH belum tentu sama dengan PHP-FPM yang melayani HTTP: web memakai socket atau pool yang terikat binary di /www/server/php/83/.
Selanjutnya, backup file situs, database, php.ini, konfigurasi pool FPM, vhost Nginx/Apache, dan metadata sertifikat sesuai prosedur Anda. Snapshot VPS dari provider sangat membantu bila tersedia. Sebelum update, catat baseline: status HTTP homepage, login admin WordPress, unggahan, cron, antrean, dan cuplikan error log. Backup data Redis hanya penting bila Redis menyimpan session atau queue yang tidak boleh hilang. Cache murni bisa Anda bangun ulang.
Untuk server dengan puluhan domain, tetapkan jendela maintenance singkat dan siapkan daftar situs kritis. Panduan setting PHP 8.3 aaPanel untuk WordPress di VPS berguna sebagai pembanding parameter php.ini sebelum dan sesudah patch, asalkan Anda tidak menyalin angka tanpa mengukur beban sendiri.
Langkah update PHP di aaPanel
Menu panel bisa sedikit berbeda antar versi aaPanel. Verifikasi label UI Anda sebelum publish internal. Agar cara update PHP di aaPanel terukur, ikuti urutan panel lalu verifikasi binary sebelum menutup maintenance. Alur umum mengikuti dokumentasi PHP Manager aaPanel.
- Buka aaPanel, masuk App Store atau Installed, pilih PHP 8.3 (sesuaikan versi yang terpasang), lalu Settings.
- Periksa versi terpasang dan jalankan update minor/patch lewat mekanisme panel. Jangan mengganti stack PHP panel dengan paket distro tanpa panduan integrasi.
- Tunggu proses selesai dan baca log instalasi bila gagal. Sukses di UI saja tidak cukup tanpa cek binary.
- Restart atau reload PHP-FPM versi terkait, bukan reboot seluruh VPS. Contoh perintah pengelolaan layanan aaPanel untuk PHP 8.3:
/etc/init.d/php-fpm-83 configtest
/etc/init.d/php-fpm-83 restart
/etc/init.d/php-fpm-83 statusKemudian verifikasi dari binary aaPanel, bukan hanya perintah php global:
/www/server/php/83/bin/php -v
/www/server/php/83/bin/php -m
/www/server/php/83/bin/php --iniPastikan socket FPM yang vhost rujuk masih hidup dan website merespons PHP. Jika Anda membuat halaman phpinfo() sementara, hapus setelah verifikasi. Bandingkan memory_limit, max_execution_time, batas unggah, disable_functions, error_reporting, dan OPcache dengan baseline. Jangan mengedit php.ini hanya karena habit: patch minor sering mempertahankan file konfigurasi, tetapi Anda tetap perlu mengecek integritasnya.
Akhirnya, audit extension yang dibutuhkan aplikasi: mysqli, mbstring, curl, intl, zip, gd, opcache, serta redis bila kode memanggil extension itu. Patch tidak otomatis membuktikan semua modul masih termuat. Jika ada kegagalan load, baca error log FPM dan perbaiki extension spesifik. Untuk strategi instalasi extension di lingkungan modern, lihat ringkasan PIE 1.5 untuk ekstensi PHP sebagai referensi, bukan pengganti panel.
Restart FPM, php.ini, dan extension setelah patch
Pertanyaan operasional sering muncul setelah patch selesai. Berikut tabel tindakan tanpa mendorong reboot atau instal ulang massal.
| Kondisi | Tindakan |
|---|---|
| Hanya patch PHP minor | Pastikan PHP-FPM memakai binary patch, lalu restart atau reload layanan FPM versi tersebut. |
php.ini tidak berubah dari baseline |
Tidak perlu edit ulang. |
Extension termuat dan lulus php -m |
Tidak perlu install ulang. |
| Extension gagal load | Perbaiki build atau kompatibilitas modul itu, jangan downgrade PHP tanpa rencana rollback. |
| Apache atau Nginx ikut diperbarui | Audit proxy HTTPS dan uji mapping vhost. Reload hanya layanan yang syntax-nya valid. |
| Redis server diperbarui | Cek daemon, persistence, dan aplikasi. Ini berbeda dari extension PHP redis. |
Redis server adalah proses penyimpanan in-memory di portnya sendiri. PHP Redis extension hanya memungkinkan skrip PHP berbicara ke daemon itu. Memperbarui salah satu tidak otomatis memperbarui yang lain.
Studi kasus HTTP 421 setelah restart stack
Kronologi dan temuan versi
Setelah PHP 8.3.36 terpasang, rekan ops memperbarui Apache, Nginx, dan Redis lalu merestart layanan web terkait. Browser menampilkan: Misdirected Request - The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection. Versi Apache yang terbaca:
/www/server/apache/bin/httpd -vOutput sesi: Apache/2.4.69 (Unix) dengan build 22 Oktober 2026, bukan 2.4.68. Peta vhost:
/www/server/apache/bin/httpd -SHTTP Apache mendengarkan port 8288, HTTPS Apache pada 8290, dengan domain utama terdaftar pada vhost dan ServerAlias yang relevan. Walau demikian, mapping ini belum membuktikan sertifikat atau SNI sudah benar untuk setiap request.
Audit vhost dan proxy Nginx
Blok SSL Apache untuk domain samaran (cuplikan baris 36–85 file vhost) memuat ServerName SSL.<domain>, alias www, sertifikat domain, SSLEngine On, dan handler PHP ke socket CGI. Nama SSL.* saja tidak otomatis menjadi akar 421 tanpa melihat jalur proxy.
Pada Nginx, grep awal hanya menemukan:
grep -nE 'proxy_pass|proxy_ssl_server_name|proxy_ssl_name' \
/www/server/panel/vhost/nginx/website-a.example.confHasil: proxy_pass https://127.0.0.1:8290; tanpa override SNI di blok yang diperiksa. Menurut dokumentasi ngx_http_proxy_module, default proxy_ssl_server_name adalah off dan default proxy_ssl_name mengikuti $proxy_host. Sedangkan backend HTTPS lokal memakai alamat loopback, hostname TLS default tidak sama dengan domain publik pengunjung.
Apache 2.4.66 ke atas memperketat kebijakan vhost TLS. Dokumentasi mod_ssl menjelaskan SSLVHostSNIPolicy secure yang dapat mengembalikan 421 bila SNI atau Host tidak cocok dengan vhost. Kasus serupa pernah dibahas di forum aaPanel untuk Apache 2.4.68, tetapi itu pembanding, bukan bukti bahwa 2.4.69 selalu gagal.
Perbaikan SNI pada proxy HTTPS
Di blok location / yang meneruskan HTTPS ke Apache, tim ops menambahkan dua direktif pada konfigurasi sesi (cuplikan disederhanakan, jangan menghapus baris lain di produksi):
location / {
proxy_pass https://127.0.0.1:8290;
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_set_header Host $host;
}Peringatan: pola ini untuk arsitektur Nginx → HTTPS Apache di localhost dengan hostname inbound yang cocok sertifikat backend. Server tanpa reverse proxy HTTPS ke Apache tidak perlu menyalin blok ini. Jangan memakai SSLVHostSNIPolicy insecure atau menonaktifkan validasi TLS sebagai jalan pintas.
Setelah simpan konfigurasi:
/www/server/nginx/sbin/nginx -t && /www/server/nginx/sbin/nginx -s reloadOutput sesi: syntax ok, test successful. Uji curl -I https://website-a.example/ (domain samaran) setara domain asli: HTTP/2 200 dengan header server: cloudflare. Meski begitu, hasil itu hanya membuktikan satu rute saat diuji, bukan seluruh fleet.
Domain kedua dan audit multi-vhost
Domain kedua juga memakai backend HTTPS Apache yang sama tanpa direktif SNI pada grep awal. Perintah perbaikan serupa disiapkan untuk klien itu, namun curl pasca-perbaikan untuk domain kedua tidak tercatat dalam sesi. Banyak file vhost memakai port 8290, tidak berarti semuanya error 421.
SOP yang aman: scan konfigurasi read-only, daftar kandidat, uji browser per domain, tandai PASS, FAIL, WARNING, atau UNVERIFIED, perbaiki hanya yang terbukti, lalu retest. Hindari skrip sed massal tanpa backup dan tanpa memeriksa konteks setiap blok location.
Checklist verifikasi setelah update PHP
- Status PHP-FPM, versi patch aktual, socket, dan daftar modul tanpa error fatal.
nginx -t,httpd -t, serta outputhttpd -Smasuk akal untuk domain produksi.- HTTPS di browser desktop (Chrome dan Firefox bila perlu) dengan hard refresh atau sesi baru.
curl -Iuntuk status dan redirect, sebagai pelengkap, bukan satu-satunya bukti.- Bila Cloudflare aktif, bedakan respons edge dari origin. Jangan bypass keamanan sertifikat hanya agar tes hijau.
- Uji homepage, login admin, halaman internal, formulir, unggahan, koneksi database, serta fungsi cache atau session Redis.
- Pantau log untuk 421, 502, 503, dan 504. Retest semua situs yang memakai stack proxy sama.
Bila performa terasa berat setelah patch, bedakan masalah runtime PHP dari bottleneck lain. Jadi, artikel diagnosis WordPress lambat di VPS aaPanel membantu memetakan lapisan sebelum Anda menaikkan spesifikasi server.
Pemulihan bila update gagal
Jangan langsung downgrade PHP atau Apache tanpa isolasi lapisan dari log dan gejala. Jika syntax config rusak, pulihkan file dari backup, uji, lalu reload. Jika extension tidak kompatibel, perbaiki modul itu atau rollback PHP hanya dengan snapshot dan rencana yang sudah diuji.
Gejala 421 setelah update stack arahkan audit ke mapping SNI dan proxy, bukan ke interpreter PHP. Kegagalan antara Cloudflare dan origin membutuhkan langkah berbeda dari kegagalan Nginx ke Apache. Perintah layanan aaPanel lainnya tercatat di dokumentasi perintah layanan aaPanel.
FAQ update PHP aaPanel
Apakah patch 8.3 ke 8.3.36 perlu reboot VPS?
Tidak wajib. Restart PHP-FPM versi terkait saja (plus layanan web bila konfigurasi berubah).
Apakah extension harus diinstall ulang?
Hanya bila modul gagal load atau build tidak cocok dengan binary patch. Jika php -m masih menampilkan extension yang dibutuhkan, tidak perlu instal ulang massal.
Apakah php.ini harus diedit lagi?
Tidak bila nilai baseline masih sama dan aplikasi berjalan normal. Patch minor jarang mengharuskan reset manual.
Apa beda patch dengan migrasi 8.2 ke 8.3?
Patch mengganti level keamanan dalam branch yang sama. Migrasi branch menuntut uji kompatibilitas kode, theme, dan plugin secara menyeluruh.
Kenapa situs error padahal PHP-FPM sudah running?
Gejala bisa dari vhost, proxy TLS, cache CDN, database, atau permission file. FPM hidup hanya membuktikan lapisan PHP, bukan seluruh rantai HTTP.
Apa arti HTTP 421 dan kaitannya dengan SNI?
Server menolak request karena hostname yang diminta tidak cocok dengan SNI atau vhost TLS pada koneksi itu. Proxy HTTPS ke Apache tanpa proxy_ssl_name yang tepat sering memicu skenario ini setelah Apache memperketat kebijakan.
Apakah proxy_ssl_server_name aman untuk semua website?
Aman bila backend TLS memang mengharapkan nama host publik yang sama dengan request pengunjung. Arsitektur berbeda (TCP plain, upstream dengan sertifikat khusus) membutuhkan analisis terpisah.
Mengapa Cloudflare 200 belum cukup?
Edge bisa merespons sukses sementara origin atau jalur proxy internal masih salah untuk domain lain. Uji langsung ke origin (dengan hati-hati) dan browser tetap diperlukan.
Apakah update Redis server wajib update extension PHP redis?
Tidak otomatis. Keduanya terkait protokol, tetapi paket dan versi dikelola lewat mekanisme berbeda. Cek keduanya bila aplikasi bergantung pada Redis.
Verifikasi akhir patch PHP dan audit stack
Patch PHP di aaPanel layak dilakukan untuk alasan keamanan dan stabilitas runtime. Prosedur aman berarti backup, verifikasi binary FPM, audit extension, serta pengujian terukur per domain. Bila Apache atau Nginx ikut diperbarui, sisihkan waktu untuk proxy TLS dan SNI sebelum menyimpulkan PHP yang rusak.
Studi kasus partner mencatat Apache 2.4.69 (build 22 Oktober 2026), PHP 8.3.36, stack Nginx front dengan HTTPS ke Apache pada port 8290, serta traffic contoh melalui Cloudflare. Sesuaikan langkah dengan versi panel dan topology server Anda, lalu dokumentasikan baseline sebelum maintenance berikutnya.
