--- title: "Perlukah HTTP/3 dan QUIC Diaktifkan di Server?" description: "Bedanya HTTP/2 dan HTTP/3, manfaat nyata di jaringan seluler, dukungan di Nginx, Caddy, LiteSpeed, dan CDN, serta urusan firewall UDP 443." url: "https://nivelva.com/insight/http3-quic-untuk-website" category: "Server \u0026 Infrastruktur" tags: ["http3","quic","nginx","caddy","kecepatan website"] author: "Theresia Candiawan" published: "2026-11-07T00:38:00+07:00" updated: "2026-11-07T00:38:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Perlukah HTTP/3 dan QUIC Diaktifkan di Server? > **Jawaban singkat:** HTTP/3 berjalan di atas QUIC (UDP), bukan TCP, sehingga koneksi lebih cepat terbentuk dan lebih tahan di jaringan seluler yang tidak stabil. Layak diaktifkan bila web server atau CDN-mu mendukungnya, asalkan UDP 443 dibuka di firewall. Browser yang tidak mendukung otomatis kembali ke HTTP/2. Umumnya ya, layak diaktifkan, terutama bila banyak pengunjungmu membuka website dari HP. Risikonya kecil karena browser yang tidak bisa memakai HTTP/3 akan kembali ke HTTP/2 tanpa pengunjung menyadarinya. Kenapa ini penting? Pengunjung dari jaringan seluler sering berpindah sinyal, kehilangan paket, atau berganti dari Wi-Fi ke data. HTTP/3 dirancang untuk kondisi seperti itu. Namun manfaatnya bergantung pada jaringan pengunjung dan cara websitemu dibangun, dan mengaktifkannya butuh satu langkah yang sering terlupa: membuka UDP port 443. Semua informasi dukungan software di artikel ini dicek **per 4 November 2026** dari dokumentasi resmi masing-masing. ## Apa bedanya HTTP/2 dan HTTP/3? Perbedaan utamanya ada di lapisan bawah. HTTP/1.1 dan HTTP/2 berjalan di atas TCP. HTTP/3 berjalan di atas QUIC, protokol transport baru yang memakai UDP dan sudah menyertakan enkripsi TLS 1.3 di dalamnya. | Aspek | HTTP/2 | HTTP/3 | |:--|:--|:--| | Transport | TCP + TLS | QUIC di atas UDP, TLS 1.3 terpadu | | Port | TCP 443 | UDP 443 | | Membentuk koneksi | Jabat tangan TCP lalu TLS | Jabat tangan transport dan kriptografi digabung | | Paket hilang | Semua stream dalam koneksi ikut tertahan | Hanya stream yang paketnya hilang yang tertahan | | Ganti jaringan (Wi-Fi ke data) | Koneksi putus, dibuat ulang | Koneksi bisa berlanjut lewat connection ID | | Penemuan oleh browser | Langsung lewat negosiasi TLS | Biasanya lewat header Alt-Svc atau record DNS HTTPS | Kolom "paket hilang" adalah inti perbedaannya. HTTP/2 mengirim banyak file sekaligus dalam satu koneksi TCP. Bila satu paket hilang, TCP menahan semua data sesudahnya sampai paket itu dikirim ulang, sehingga semua file ikut menunggu. Di QUIC, setiap stream berdiri sendiri, jadi paket yang hilang hanya memperlambat file yang bersangkutan. ## Apakah HTTP/3 benar-benar membuat website lebih cepat? Tergantung kondisi jaringan pengunjung. Di jaringan kabel atau Wi-Fi kantor yang stabil, selisih HTTP/2 dan HTTP/3 sering kecil. Di jaringan seluler dengan latensi tinggi dan paket yang kadang hilang, keunggulan QUIC lebih mungkin terasa: koneksi terbentuk lebih cepat dan halaman tidak macet karena satu paket yang terlambat. Yang perlu diingat, HTTP/3 tidak memperbaiki masalah di sisi server. Halaman yang lambat karena query database berat, gambar berukuran besar, atau JavaScript berlebihan tetap lambat lewat protokol apa pun. Perbaiki hal-hal itu dulu, baru HTTP/3 menjadi lapisan tambahan. ## Bagaimana dukungan di web server dan CDN? ### Nginx Dokumentasi resmi menyebut dukungan QUIC dan HTTP/3 tersedia sejak versi 1.25.0 dan sudah disertakan di paket biner Linux resmi nginx.org. Halaman modul `ngx_http_v3_module` masih menandainya **eksperimental**. Untuk membangun sendiri, Nginx merekomendasikan OpenSSL 3.5.1 atau lebih baru, atau pustaka alternatif seperti BoringSSL, LibreSSL, dan QuicTLS. Konfigurasinya menambah parameter `quic` pada `listen` di port yang sama dengan HTTPS, plus header Alt-Svc untuk memberi tahu browser: ``` server { listen 443 quic reuseport; listen 443 ssl; ssl_certificate /etc/ssl/domain.crt; ssl_certificate_key /etc/ssl/domain.key; add_header Alt-Svc 'h3=":443"; ma=86400'; } ``` Parameter `reuseport` cukup ditulis di satu blok server untuk setiap kombinasi alamat dan port. Paket Nginx bawaan distribusi Linux belum tentu dibangun dengan modul HTTP/3, jadi cek dengan `nginx -V`. ### Caddy Caddy paling sederhana. Dokumentasi opsi `protocols` menyebut nilai defaultnya `h1 h2 h3`, artinya HTTP/3 sudah aktif tanpa konfigurasi tambahan. Yang perlu kamu lakukan hanya membuka UDP 443. Cara memasangnya ada di [cara pasang Caddy sebagai reverse proxy](https://nivelva.com/insight/pasang-caddy-reverse-proxy). ### LiteSpeed Dokumentasi LiteSpeed untuk lingkungan cPanel menyatakan QUIC aktif secara default di LiteSpeed Web Server, dengan syarat UDP 443 dibuka dan sertifikat yang dipakai tepercaya (bukan self-signed). Perbandingan ketiga web server ini ada di [Nginx vs Apache vs LiteSpeed](https://nivelva.com/insight/nginx-apache-litespeed). ### CDN Bila website memakai CDN, HTTP/3 biasanya diaktifkan di sisi CDN, bukan di servermu. Sebagai contoh, dokumentasi Cloudflare menyebut HTTP/3 tersedia di semua paket (Free, Pro, Business, Enterprise) dan diaktifkan lewat menu Speed, Settings, Protocol Optimization. Cloudflare juga mencatat bahwa koneksi HTTP/3 ke server asal belum didukung, jadi HTTP/3 berlaku antara pengunjung dan CDN, sementara CDN ke servermu tetap memakai TCP. Konsep CDN dijelaskan di [apa itu CDN](https://nivelva.com/insight/apa-itu-cdn). ## Kenapa HTTP/3 sudah diaktifkan tapi tidak dipakai? Penyebab paling sering adalah **UDP 443 tertutup**. Banyak firewall dikonfigurasi dengan pola "izinkan TCP 80 dan 443" saja. Karena HTTP/3 memakai UDP, browser mencoba, gagal, lalu diam-diam tetap memakai HTTP/2. Di UFW, buka dengan: ``` sudo ufw allow 443/udp ``` Di iptables, aturannya `iptables -I INPUT -p udp --dport 443 -j ACCEPT`. Cek juga firewall di panel penyedia server bila ada. Bila server memakai CSF, dokumentasi LiteSpeed menyarankan menambah 443 ke daftar UDP_IN dan UDP_OUT. > **Browser tidak langsung memakai HTTP/3:** > > Pada kunjungan pertama, browser biasanya terhubung lewat HTTP/2, membaca header Alt-Svc, lalu memakai HTTP/3 di permintaan berikutnya. Jadi wajar bila pengujian pertama masih menunjukkan h2. Muat ulang halaman, lalu periksa kolom Protocol di tab Network developer tools browser. Penyebab lain: jaringan kantor atau operator tertentu memblokir UDP, sehingga pengunjung dari sana tetap memakai HTTP/2. Ini bukan kesalahan servermu, dan pengunjung tetap terlayani lewat fallback. Daftar port yang perlu terbuka di server ada di [port penting di server](https://nivelva.com/insight/port-penting-server). ## Cara mengecek HTTP/3 sudah berjalan Tiga cara sederhana: - **Header respons.** `curl -sI https://domainmu.com` harus menampilkan baris `alt-svc` yang berisi `h3`. - **Browser.** Di developer tools, tab Network, tampilkan kolom Protocol. Nilai `h3` berarti HTTP/3 dipakai. - **curl dengan HTTP/3.** Bila curl di komputermu dibangun dengan dukungan HTTP/3, `curl --http3 -I https://domainmu.com` mencoba langsung lewat QUIC. ## Pertanyaan yang sering diajukan ### Apakah HTTP/3 menggantikan HTTP/2 sepenuhnya? Tidak. Server tetap melayani HTTP/1.1 dan HTTP/2 untuk klien yang tidak bisa memakai HTTP/3 atau jaringan yang memblokir UDP. HTTP/3 ditambahkan, bukan menggantikan. ### Apakah HTTP/3 lebih aman? QUIC selalu terenkripsi dengan TLS 1.3, jadi tidak ada versi tanpa enkripsi. Tapi keamanan aplikasi, seperti celah di plugin atau password lemah, tidak berubah karena protokol. ### Perlukah HTTP/3 untuk API yang dipakai server lain? Biasanya tidak mendesak. Komunikasi antar server di pusat data umumnya stabil, sehingga keunggulan QUIC lebih kecil. Prioritaskan HTTP/3 untuk pengunjung manusia, terutama pengguna HP. HTTP/3 adalah peningkatan yang murah risikonya: aktifkan di web server atau CDN, buka UDP 443, lalu cek kolom protokol di browser. Kalau ada yang tidak beres, pengunjung tetap dilayani lewat HTTP/2. ## Sumber - - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/http3-quic-untuk-website Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com