File php.ini adalah konfigurasi utama PHP yang mengontrol batas sumber daya, keamanan, dan perilaku runtime server web. Mengedit parameter seperti memory_limit, upload_max_filesize, dan max_execution_time memengaruhi performa aplikasi, namun perubahan hanya berlaku setelah layanan PHP di-restart dan harus mematuhi hierarki ketat antar-parameter.
Mengapa File php.ini Menjadi Jantung Konfigurasi Server?
Banyak developer menganggap php.ini sekadar tempat menaruh angka untuk menghindari error. Pada kenyataannya, file ini adalah batas negosiasi antara mesin virtual PHP dan sistem operasi. Ketika Anda menyetel memory_limit, Anda tidak hanya memberi tahu PHP berapa banyak RAM yang boleh digunakan. Anda secara tidak langsung memengaruhi berapa banyak worker process yang bisa dijalankan oleh PHP-FPM secara konkuren.
Kesalahan dalam mengonfigurasi file ini tidak hanya membuat aplikasi error, tetapi dapat memicu Out of Memory (OOM) Killer di level sistem operasi yang akan membunuh proses web server secara paksa. Memahami php.ini berarti memahami arsitektur sumber daya server Anda.
Bagaimana Hierarki File Konfigurasi PHP Bekerja?
Salah satu miskonsepsi terbesar adalah menganggap hanya ada satu file php.ini di server. Pada lingkungan modern, PHP menggunakan hierarki konfigurasi bertingkat yang saling override.
- Global
php.ini: Biasanya terletak di/etc/php/8.x/fpm/php.ini. Ini mengontrol seluruh server dan hanya bisa diedit oleh root. - Pool Configuration: File seperti
/etc/php/8.x/fpm/pool.d/www.confdapat meng-override nilai denganphp_admin_valueyang tidak bisa ditimpa dari level bawah. .user.ini: File konfigurasi per-direktori. PHP mencari file ini di direktori script yang dieksekusi dan naik ke direktori induknya.- Override Web Server: Apache atau Nginx dapat meng-override nilai PHP melalui konfigurasi virtual host.
- Reverse Proxy Limits: Nginx (
client_max_body_size) atau Apache (LimitRequestBody) dapat menolak request sebelum sampai ke PHP.
Memahami hierarki ini sangat krusial. Jika Anda menggunakan shared hosting, Anda hampir pasti tidak mengedit php.ini global, melainkan .user.ini atau menggunakan panel seperti cPanel.
Parameter Utama php.ini dan Trade-off Pengaturannya
Mengubah parameter tanpa memahami hubungan antar-variabel adalah penyebab utama server menjadi tidak stabil. Berikut adalah parameter kritis dan logika di baliknya.
Apa yang Terjadi Jika Memory Limit Disetel Terlalu Tinggi?
Menyetel memory_limit = -1 (unlimited) atau nilai sangat besar seperti 2048M sering disarankan di forum untuk mengatasi error Fatal error: Allowed memory size exhausted. Ini adalah solusi berbahaya. Jika Anda memiliki 8GB RAM dan menyetel memory_limit menjadi 4GB, PHP-FPM mungkin mengizinkan 2 proses berjalan sebelum memori habis.
Namun, jika lonjakan trafik terjadi dan 10 proses berjalan bersamaan, server akan kehabisan RAM dan crash. Aturan Praktisi: Setel memory_limit serapat mungkin dengan kebutuhan aplikasi (misal 256M atau 512M), lalu optimasi kode atau tingkatkan pm.max_children di PHP-FPM dengan nilai yang lebih kecil.
Mengapa Upload File Gagal Meski upload_max_filesize Sudah Diperbesar?
Ini adalah jebakan klasik. Anda mengubah upload_max_filesize = 100M, tetapi file 50MB tetap gagal diunggah. Penyebabnya adalah Anda mengabaikan parameter lain yang saling bergantung. Agar upload file berhasil, Anda harus mematuhi aturan hierarki ukuran ini: memory_limit > post_max_size > upload_max_filesize.
Jika upload_max_filesize adalah 100M, maka post_max_size minimal harus 100M (disarankan 105M untuk overhead), dan memory_limit harus lebih besar dari post_max_size. Jika salah satu rantai ini putus, PHP akan menolak permintaan secara diam-diam atau mengembalikan error kosong.
Kapan max_execution_time vs max_input_time Harus Diubah?
Dua parameter ini sering tertukar karena mengukur fase berbeda:
max_input_time: Waktu maksimum untuk menerima dan mem-parsing data request, termasuk durasi upload file. Jika upload file besar lambat, naikkan parameter ini.max_execution_time: Waktu maksimum eksekusi script setelah parsing selesai. Nilai default biasanya 30 detik.
Mengubah max_execution_time menjadi 300 detik mungkin diperlukan untuk proses cron job atau impor data besar. Namun, risikonya adalah memblokir worker PHP-FPM. Jika Anda memiliki 10 worker dan 10 pengguna menjalankan script 300 detik secara bersamaan, seluruh website Anda akan mengalami downtime selama 5 menit karena tidak ada worker yang tersisa.
Parameter Keamanan yang Sering Diabaikan
open_basedir: Membatasi akses filesystem PHP hanya ke direktori tertentu. Ini adalah lapisan keamanan tambahan, bukan pengganti permission filesystem yang benar. Dokumentasi resmi PHP secara eksplisit menyebutnya hanya sebagai jaring pengaman yang tidak komprehensif.
display_errors: Mengatur apakah error ditampilkan di halaman. display_errors = On di server produksi adalah risiko keamanan nyata karena error PHP sering membocorkan path absolut, struktur database, atau kredensial.
max_file_uploads: Membatasi jumlah file yang bisa diupload dalam satu request. Parameter ini sering terlewat saat troubleshooting karena gejalanya membingungkan: aplikasi menerima sebagian file dari batch upload, lalu diam-diam mengabaikan sisanya tanpa pesan error eksplisit.
| Parameter | Fungsi Utama | Trade-off / Risiko | Aturan Hierarki |
|---|---|---|---|
memory_limit |
Batas RAM per script | Bisa memicu OOM Killer jika terlalu besar | Harus > post_max_size |
post_max_size |
Batas ukuran data POST | Menolak upload jika lebih kecil dari file | Harus > upload_max_filesize |
upload_max_filesize |
Batas ukuran satu file upload | Tidak berlaku jika post_max_size lebih kecil |
Nilai dasar target upload |
max_execution_time |
Batas waktu eksekusi script | Memblokir worker PHP-FPM jika terlalu lama | Hindari untuk request web publik |
max_input_time |
Batas waktu parsing request | Upload file besar butuh nilai lebih tinggi | Naikkan jika upload lambat |
max_file_uploads |
Batas jumlah file per request | Batch upload bisa gagal diam-diam | Sesuaikan dengan kebutuhan aplikasi |
open_basedir |
Batasan akses direktori | Terlalu ketat: aplikasi gagal baca file | Lapisan keamanan tambahan |
display_errors |
Tampilan error di halaman | On di produksi = risiko keamanan | Off untuk production |
Kesalahan yang Menyebabkan Perubahan php.ini Tidak Berfungsi
Anda telah mengedit file, menyimpannya, dan me-refresh halaman, tetapi phpinfo() masih menunjukkan nilai lama. Berikut adalah root cause yang paling sering terjadi di lapangan.
1. Mengedit File php.ini yang Salah
Server modern memisahkan konfigurasi untuk CLI (Command Line Interface) dan FPM/Apache. Mengedit /etc/php/8.2/cli/php.ini tidak akan mengubah apa pun di website Anda. Anda harus mengedit versi FPM atau Apache.
2. Lupa Melakukan Restart Layanan PHP
Berbeda dengan .htaccess yang langsung dibaca, php.ini global di-cache ke dalam memori saat layanan dimulai. Anda wajib menjalankan sudo systemctl reload php8.2-fpm (untuk Nginx/PHP-FPM) atau restart Apache. Gunakan reload bukan restart untuk menghindari memutus koneksi aktif.
3. Terjebak Cache .user.ini
Jika Anda menggunakan .user.ini, PHP melakukan cache terhadap file ini. Perubahan tidak langsung aktif karena adanya parameter user_ini.cache_ttl (default 300 detik). Anda harus menunggu 5 menit atau me-restart PHP-FPM untuk memaksa reload.
4. Kesalahan Sintaks yang Merusak Parser
Jika Anda tidak sengaja menghapus tanda kutip atau titik koma di php.ini, parser PHP akan gagal membaca seluruh file. Akibatnya, PHP akan fallback ke nilai compiled default (bawaan pabrik), yang seringkali jauh lebih ketat. Selalu validasi dengan php-fpm -t sebelum reload.
5. Override dari Reverse Proxy
Nginx memiliki client_max_body_size (default 1M) yang dapat menolak request upload besar sebelum sampai ke PHP. Apache memiliki LimitRequestBody. Jika perubahan upload_max_filesize tidak berpengaruh, cek konfigurasi reverse proxy Anda.
Checklist Debugging php.ini Tidak Berubah
- Cek lokasi file aktif melalui
phpinfo()pada baris Loaded Configuration File - Pastikan Anda mengedit file untuk SAPI yang benar (FPM, bukan CLI)
- Validasi sintaks dengan
php-fpm -tsebelum reload - Reload layanan PHP-FPM atau Apache setelah menyimpan file
- Cek error log PHP (
/var/log/php-fpm.log) untuk mendeteksi kesalahan sintaks - Jika menggunakan
.user.ini, tunggu waktuuser_ini.cache_ttlatau restart FPM - Cek konfigurasi reverse proxy (Nginx
client_max_body_size, ApacheLimitRequestBody) - Verifikasi tidak ada override di pool FPM (
php_admin_value) atau.htaccess
X vs Y: Mengedit via php.ini, .htaccess, atau .user.ini?
Memilih metode override yang tepat bergantung pada arsitektur server dan hak akses Anda. Menggunakan metode yang salah tidak hanya gagal, tetapi bisa membuat website menampilkan error 500.
| Metode | Lingkungan | Cara Penulisan | Kapan Harus Digunakan? |
|---|---|---|---|
| php.ini | Global (VPS/Dedicated) | directive = value |
Untuk konfigurasi dasar server yang memengaruhi semua situs |
| .htaccess | Apache (mod_php) | php_value directive value |
Hanya untuk Apache dengan mod_php. Akan error 500 di PHP-FPM |
| .user.ini | PHP-FPM / CGI | directive = value |
Untuk shared hosting atau override per-direktori di PHP-FPM |
| ini_set() | Level Script PHP | ini_set('directive', 'value'); |
Untuk override dinamis, tidak berlaku untuk semua direktif |
| Pool FPM | PHP-FPM | php_admin_value[directive] = value |
Override yang tidak bisa ditimpa dari level bawah |
Catatan Kritis untuk PHP-FPM:
Jika Anda menggunakan Nginx dengan PHP-FPM, direktif php_value di .htaccess tidak akan dikenali. Anda harus menggunakan .user.ini atau mengatur php_admin_value di konfigurasi pool PHP-FPM. Tidak semua parameter bisa diubah lewat ini_set(). Parameter dengan mode PHP_INI_SYSTEM hanya bisa diubah lewat php.ini atau konfigurasi web server, bukan dari dalam kode PHP.
Bagaimana Status Versi PHP Memengaruhi Konfigurasi?
Per Juni 2026, hanya PHP 8.2, 8.3, 8.4, dan 8.5 yang masih mendapat dukungan resmi. PHP 8.1 ke bawah telah mencapai end-of-life (EOL), dan PHP 8.2 akan EOL pada 31 Desember 2026. Ini relevan untuk konfigurasi php.ini karena:
- Mengedit parameter di server yang menjalankan versi PHP EOL hanya menunda gejala, bukan menyelesaikan masalah keamanan yang lebih besar
- PHP 8.3 adalah rekomendasi paling stabil untuk produksi (didukung hingga November 2027)
- PHP 8.4 dan 8.5 menawarkan dukungan jangka panjang lebih jauh ke depan
Parameter php.ini sendiri relatif stabil antar versi, tetapi versi PHP yang berjalan menentukan parameter mana yang relevan dan seberapa darurat sebuah upgrade dilakukan.
Bagaimana Cara Mengedit php.ini dengan Aman di Berbagai Lingkungan?
Pendekatan pengeditan sangat bergantung pada infrastruktur yang Anda gunakan. Memaksakan akses root di lingkungan managed hosting adalah pendekatan yang keliru.
Di Shared Hosting (cPanel / Plesk):
Jangan mencari file php.ini melalui File Manager. Gunakan fitur bawaan seperti “MultiPHP INI Editor” di cPanel atau “PHP Settings” di Plesk. Panel ini akan menulis ke .user.ini atau file konfigurasi global secara aman di balik layar.
Di VPS / Cloud (Ubuntu / Debian):
Gunakan terminal. Temukan file yang tepat dengan perintah php --ini untuk CLI, atau cek phpinfo() untuk FPM. Edit menggunakan nano atau vim, lalu selalu validasi sintaks dengan php-fpm -t sebelum reload layanan.
Di Docker / Container:
Jangan mengedit file php.ini secara manual di dalam container yang berjalan, karena perubahan akan hilang saat container di-recreate. Gunakan perintah docker-php-ext-configure atau salin file konfigurasi kustom Anda ke /usr/local/etc/php/ melalui Dockerfile.
Proses Edit yang Benar:
- Temukan file aktif dengan
php --iniatauphpinfo() - Backup file asli:
sudo cp php.ini php.ini.bak - Edit dengan akses root/sudo
- Validasi konfigurasi:
php-fpm -t - Reload layanan:
systemctl reload php8.3-fpm - Verifikasi dari sisi yang sama dengan request asli (bukan CLI)
Memperlakukan php.ini sebagai dokumen hidup yang memerlukan pemahaman arsitektur, bukan sekadar daftar angka untuk ditiru dari internet, adalah pembeda antara developer pemula dan engineer yang mampu menjaga stabilitas sistem produksi.
FAQ
Mengapa perubahan di php.ini tidak langsung terlihat di website?
Kemungkinan besar Anda mengedit file php.ini untuk CLI, bukan untuk FPM/Apache, atau Anda lupa me-reload layanan PHP. Jika menggunakan .user.ini, perubahan di-cache selama 5 menit secara default. Cek juga reverse proxy limits seperti Nginx client_max_body_size.
Apa bedanya php.ini dan .user.ini?
php.ini adalah konfigurasi global server yang memerlukan akses root dan reload layanan untuk berlaku. .user.ini adalah konfigurasi per-direktori untuk pengguna shared hosting atau PHP-FPM, yang dimuat ulang secara otomatis berdasarkan nilai user_ini.cache_ttl (default 300 detik).
Mengapa upload file tetap gagal padahal upload_max_filesize sudah diubah?
Anda mungkin mengabaikan parameter post_max_size, memory_limit, atau reverse proxy limits. Aturan mutlaknya adalah: memory_limit > post_max_size > upload_max_filesize. Cek juga client_max_body_size di Nginx atau LimitRequestBody di Apache.
Apakah aman menyetel memory_limit ke -1 (unlimited)?
Tidak aman untuk lingkungan web publik. Menyetelnya ke -1 berarti script bisa mengonsumsi seluruh RAM server hingga memicu Out of Memory (OOM) Killer, yang akan membunuh proses web server dan membuat website mati total.
Bagaimana cara mengetahui lokasi file php.ini yang sedang aktif?
Buat file PHP berisi <?php phpinfo(); ?>, buka di browser, dan cari baris Loaded Configuration File. Lokasi yang tertera di sana adalah file yang sedang dibaca oleh web server Anda saat ini. Untuk CLI, gunakan php --ini.
Mengapa website error 500 setelah menambahkan php_value di .htaccess?
Anda kemungkinan menggunakan PHP-FPM (umum di Nginx atau Apache modern). PHP-FPM tidak mendukung php_value di .htaccess. Gunakan .user.ini sebagai gantinya, atau atur via php_admin_value di pool konfigurasi FPM.
Apakah saya perlu restart seluruh server setiap edit php.ini?
Tidak. Cukup reload (bukan restart penuh) layanan PHP-FPM atau web server yang relevan dengan systemctl reload php8.3-fpm. Restart penuh server hanya diperlukan dalam kasus yang sangat jarang, seperti perubahan konfigurasi level sistem operasi.
