Generator .htaccess
Buat aturan Apache .htaccess untuk konfigurasi server umum.
Paksa HTTPS
Paksa WWW / tanpa WWW
Header keamanan
Kompresi GZIP
Caching browser
Halaman kesalahan kustom
Opsi direktori
File .htaccess yang dihasilkan
Apa itu .htaccess?
File .htaccess adalah file konfigurasi untuk server web Apache. Memungkinkan Anda menentukan pengalihan URL, header keamanan, aturan cache, dan lainnya · tanpa memodifikasi konfigurasi server utama.
Pertanyaan umum
Di mana menempatkan file .htaccess?
Tempatkan di direktori root situs Anda (biasanya public_html atau www). Aturan berlaku untuk direktori itu dan semua subdirektorinya.
Apakah ini akan berfungsi dengan Nginx?
Tidak. .htaccess spesifik untuk Apache. Nginx menggunakan sintaks konfigurasinya sendiri dalam nginx.conf atau file konfigurasi situs.
Bisakah .htaccess memperlambat situs saya?
Apache memeriksa .htaccess pada setiap permintaan, jadi file yang sangat besar dapat menambahkan overhead. Untuk situs dengan lalu lintas tinggi, memindahkan aturan ke konfigurasi Apache utama lebih cepat.
Apa sebenarnya .htaccess itu
File .htaccess adalah file konfigurasi per-direktori Apache. Nama ini secara luas dipahami sebagai singkatan dari «hypertext access», mencerminkan kegunaan utama file ini pada awalnya untuk membatasi akses ke dokumen hypertext. Letakkan satu di direktori mana pun dan direktif berlaku untuk direktori tersebut dan setiap subdirektori di bawahnya. File ini tidak memiliki nama sebelum titik (ini adalah file titik Unix, tersembunyi secara default) dan harus diberi nama persis .htaccess (huruf kecil, titik di awal) agar Apache dapat menemukannya di bawah pengaturan AccessFileName default.
Ada biaya performa nyata. Dokumentasi Apache menyatakannya secara eksplisit: «jika AllowOverride diatur untuk mengizinkan penggunaan file .htaccess, Apache akan mencari file .htaccess di setiap direktori. Dengan demikian, mengizinkan file .htaccess menyebabkan penurunan performa, terlepas dari apakah Anda benar-benar menggunakannya atau tidak.» Pohon direktori dijelajahi pada setiap permintaan HTTP. Untuk permintaan ke /var/www/html/foo/bar/baz.html, Apache memeriksa /.htaccess, kemudian /var/.htaccess, kemudian /var/www/.htaccess, kemudian /var/www/html/.htaccess, dan seterusnya, bahkan ketika tidak ada file tersebut yang ada. Rekomendasi Apache sendiri adalah menggunakan blok <Directory> main-config jika memungkinkan (diuraikan sekali saat startup), dan menyimpan .htaccess untuk lingkungan hosting di mana Anda tidak memiliki akses main-config.
Kapan Anda membutuhkannya (dan kapan tidak)
Apache mencantumkan dua kasus penggunaan yang sah untuk .htaccess: penyedia hosting yang memberi pengguna kontrol terbatas tanpa akses konfigurasi server penuh, dan kasus di mana direktif perlu berbeda di antara subdirektori di mana deployer hanya mengontrol sistem file. Di luar itu, dokumentasi secara eksplisit merekomendasikan memindahkan aturan ke blok <Directory> di konfigurasi utama.
nginx (web server terpopuler kedua) tidak mendukung .htaccess sama sekali; ia dengan sengaja menolak file konfigurasi per-direktori demi alasan performa, dan semua konfigurasi berada di nginx.conf dan file situs yang disertakan. Jika proyek Anda ada di nginx, output generator ini tidak akan membantu, Anda memerlukan blok server / location di file konfigurasi nginx. Caddy menggunakan sintaks Caddyfile-nya sendiri dengan HTTPS otomatis via Let's Encrypt sebagai default. LiteSpeed dan OpenLiteSpeed mendukung .htaccess untuk kompatibilitas Apache. IIS menggunakan web.config.
Penulisan ulang URL dan pola HTTPS kanonik
Sebagian besar pekerjaan .htaccess non-trivial menggunakan mod_rewrite, mesin penulisan ulang URL berbasis aturan Apache yang dibangun di atas ekspresi reguler POSIX extended. Bentuk dasarnya adalah RewriteRule pattern substitution [flags], opsional didahului oleh satu atau lebih kondisi RewriteCond. Blok force-HTTPS standar:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Flag [L,R=301] berarti «ini adalah aturan terakhir dalam putaran ini» dan «respons dengan HTTP 301 Moved Permanently.» 301 adalah pilihan yang tepat untuk redirect permanen, mesin pencari meneruskan ekuitas tautan dan browser melakukan cache secara agresif. Gunakan 302 (Found) hanya untuk redirect yang benar-benar sementara, di mana Anda tidak menginginkan perpindahan tersebut di-cache.
Di belakang load balancer atau reverse proxy yang mengakhiri TLS, server asal melihat HTTP biasa meskipun browser pengguna menggunakan HTTPS; aturan RewriteCond %{HTTPS} off yang naif kemudian melakukan redirect selamanya. Perbaikannya adalah memeriksa header yang diteruskan: RewriteCond %{HTTP:X-Forwarded-Proto} !https. Mode «Flexible SSL» Cloudflare (CDN berbicara HTTP ke asal sementara pengguna menggunakan HTTPS) adalah penyebab paling umum dari jebakan redirect-loop ini.
Pilih antara kanonisasi www dan non-www dengan pola serupa. Pilih satu hostname kanonik untuk SEO (menghindari masalah konten duplikat) dan untuk ruang lingkup cookie (subdomain www menerima cookie yang berbeda dari apex secara default).
Kompresi dan caching
mod_deflate mengompresi respons tekstual dengan gzip, secara dramatis mengurangi ukuran transfer pada text/HTML/CSS/JS. Bungkus blok dalam <IfModule mod_deflate.c> agar tidak merusak situs di server di mana modul tersebut tidak dimuat. Brotli (mod_brotli) adalah pengganti modern dan menggunakan pola yang sama.
mod_expires menetapkan header Expires dan Cache-Control: max-age. Sintaks «access plus 1 year» yang banyak digunakan berarti aset dapat di-cache selama satu tahun sejak pengguna mengambilnya. Max-age panjang tepat untuk nama file aset yang di-hash (app.abc123.js); max-age lebih pendek tepat untuk HTML dan segala sesuatu yang bisa berubah. Untuk kontrol yang lebih halus, Header set Cache-Control "public, max-age=31536000, immutable" pada file yang di-hash adalah praktik terbaik modern.
Header keamanan yang perlu diketahui
- X-Frame-Options: SAMEORIGIN: mencegah halaman disematkan dalam
<iframe>di origin lain. Sebagian besar digantikan oleh CSPframe-ancestors. - Content-Security-Policy: pertahanan utama modern terhadap XSS dan click-jacking. Sebagai permulaan:
default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'. Perketat seiring waktu. - Strict-Transport-Security (HSTS), memberi tahu browser untuk hanya berbicara HTTPS ke domain Anda.
max-age=31536000; includeSubDomainsadalah baseline tipikal. Tambahkanpreloadhanya ketika Anda yakin HTTPS bersifat permanen; setelah dimuat sebelumnya ke daftar HSTS browser, penghapusannya sulit. - X-Content-Type-Options: nosniff: mencegah browser menebak sendiri header
Content-Type. Header ini hanya memiliki satu nilai. - Referrer-Policy: strict-origin-when-cross-origin: default modern; mengirim URL lengkap ke permintaan same-origin, hanya origin ke permintaan cross-origin, dan tidak ada apa pun pada downgrade HTTPS-ke-HTTP.
- Permissions-Policy: mengontrol fitur browser seperti kamera, mikrofon, geolokasi. Menggantikan header Feature-Policy yang lebih lama.
- X-XSS-Protection: sebagian besar sudah usang. Filter telah dihapus dari Chrome dan tidak pernah ada di Firefox; keamanan modern mengandalkan CSP. Banyak panduan lama masih mengirimkannya untuk IE lama, aman untuk dihilangkan di situs baru.
Sembunyikan apa yang tidak boleh dilayani
Dua one-liner penguatan keamanan yang terbayar sendiri:
Options -Indexes: menonaktifkan daftar direktori yang dibuat otomatis ketika tidak adaindex.html. Banyak distribusi menyertakan pengindeksan direktori secara default; direktori yang tidak terjaga dan tidak terlindungi tidak boleh membocorkan isinya ke web.- Blokir dot-file dan metadata source-control. Blok
<FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$">denganRequire all deniedmenghentikan penyerang mengunduh.env(yang sering berisi password DB dan kunci API) atau.git/config(yang mengekspos URL remote dan terkadang kredensial). Laporan ancaman Akamai dan SANS mendokumentasikan paparan.envsebagai salah satu kebocoran lapisan aplikasi yang paling umum di tahun 2020-an.
Apache 2.4 menggantikan sintaks Order Allow,Deny yang lebih lama dengan keluarga direktif Require yang lebih bersih, Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5. Sintaks lama masih berfungsi untuk kompatibilitas mundur tetapi didokumentasikan sebagai usang.
Kesalahan umum
- mod_rewrite harus diaktifkan di tingkat server. Di Debian/Ubuntu:
sudo a2enmod rewrite && sudo systemctl restart apache2. Tanpanya, setiapRewriteRuledilewati secara diam-diam. - AllowOverride penting. Jika konfigurasi utama memiliki
AllowOverride Noneuntuk<Directory>Anda, setiap direktif dalam.htaccessAnda diabaikan secara diam-diam.AllowOverride Allmengizinkan semuanya;AllowOverride FileInfo AuthConfighanya mengizinkan penulisan ulang dan autentikasi, yang cukup untuk sebagian besar kasus penggunaan. - Satu kesalahan ketik dapat merusak seluruh situs. Apache mengembalikan 500 Internal Server Error untuk setiap permintaan ke pohon direktori yang terpengaruh sampai file diperbaiki. Selalu uji di staging terlebih dahulu; simpan salinan cadangan bernama
.htaccess.bak; siapkan akses SSH/FTP sehingga Anda dapat mengganti nama file yang rusak dari jarak jauh. Pantau/var/log/apache2/error.loguntuk pesan sintaks. - Loop redirect tak terbatas. Browser membatasi rantai redirect sekitar 20 hop dan menampilkan
ERR_TOO_MANY_REDIRECTS. Penyebab paling umum: aturan redirect HTTPS berjalan di server di belakang proxy penghentian TLS (gunakan%{HTTP:X-Forwarded-Proto}); aturan www dan HTTPS dalam urutan yang salah menyebabkan redirect ganda; mode Flexible SSL Cloudflare. - Flag
[L]menjalankan ulang mesin rewrite dari atas dengan URL yang telah ditulis ulang. Jika aturan selanjutnya kemudian cocok, perilakunya bisa mengejutkan. Gunakan[END](Apache 2.3.9+) ketika Anda benar-benar menginginkan penghentian penuh. - Konteks per-direktori menghilangkan garis miring di awal. Dalam
.htaccess,RewriteRule ^index\.html$ home.htmlcocok;RewriteRule ^/index\.html$tidak. Ini mengejutkan semua orang yang menyalin aturan dari contoh konfigurasi utama. - Beberapa direktif dilarang dalam .htaccess:
<VirtualHost>,<Directory>,<Location>,Listen,ServerNamehanya untuk main-config. File per-direktori sudah secara implisit berlaku untuk direktorinya sendiri.
Pertanyaan lainnya
Di mana tepatnya file ini harus diletakkan?
Di direktori yang isinya ingin Anda kontrol. Sebagian besar pengguna shared-hosting meletakkannya di document root situs mereka, public_html/, www/, atau htdocs/ tergantung pada host. Apache kemudian menjelajahi pohon direktori menerapkan aturan ke direktori tersebut dan setiap subdirektori di bawahnya.
301 atau 302, redirect mana yang harus saya gunakan?
301 Moved Permanently untuk perpindahan permanen. Mesin pencari mentransfer ekuitas tautan ke URL baru; browser melakukan cache redirect secara agresif. Gunakan ini untuk kasus «kami memindahkan halaman ini selamanya». 302 Found untuk redirect sementara, browser tidak melakukan cache dan mesin pencari tidak mentransfer peringkat. Gunakan 302 hanya ketika perpindahan tersebut memang sementara; menjadikan 302 sebagai default alih-alih 301 adalah salah satu kesalahan SEO yang paling umum.
Bagaimana cara melindungi direktori dengan kata sandi?
Buat file .htpasswd dengan utilitas command-line htpasswd (ia menyimpan baris username:bcrypt-hash) dan simpan di luar root web Anda. Kemudian dalam .htaccess: AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user. Browser menampilkan prompt Basic-auth sistem ke siapa pun yang mengunjungi direktori. Ini adalah pola Apache klasik; untuk autentikasi yang serius pertimbangkan sistem login tingkat aplikasi.
Apakah ini akan berfungsi di WordPress?
WordPress dikirimkan dengan blok .htaccess-nya sendiri (antara penanda # BEGIN WordPress dan # END WordPress) yang menangani permalink. WordPress akan menimpa apa pun di dalam penanda tersebut ketika Anda menyimpan pengaturan permalink. Tambahkan aturan Anda sendiri di luar penanda WordPress (biasanya di atasnya) agar aturan tersebut bertahan dari regenerasi otomatis.
Apakah ada yang dikirim ke server?
Tidak. Generator adalah JavaScript yang merakit blok direktif berdasarkan kotak centang Anda; output dibuat di browser Anda. Tidak ada yang berkaitan dengan domain atau opsi yang Anda pilih meninggalkan halaman; alat ini berfungsi secara offline setelah dimuat.