Deploy Static Site dengan Nginx + HTTP/3 (QUIC) di VPS Ubuntu

Beberapa bulan lalu saya iseng mengukur performa salah satu situs dokumentasi yang saya host. Situs-nya statis — cuma HTML, CSS, dan sedikit JavaScript — tapi waktu load dari koneksi mobile di Indonesia terasa lambat. Setelah di-inspect, masalahnya bukan di ukuran file, tapi di protokol: masih HTTP/2 over TCP, dan setiap kali koneksi mobile berpengaruhan sinyal jelek, TCP handshake yang hilang satu paket saja bikin seluruh koneksi stall.

Solusinya: pindah ke HTTP/3, yang berjalan di atas QUIC (berbasis UDP, bukan TCP). QUIC menyelesaikan masalah head-of-line blocking TCP dan bikin koneksi lebih tahan terhadap packet loss — persis kondisi jaringan mobile Indonesia yang tidak stabil. Setelah migrasi, metrik Core Web Vitals situs itu membaik noticeably, terutama di koneksi yang tidak ideal.

Artikel ini tutorial lengkap cara deploy static site di VPS Ubuntu dengan Nginx yang support HTTP/3/QUIC, dari nol sampai terverifikasi jalan. Saya pakai Nginx mainline (yang sudah support QUIC native sejak 1.25) jadi tidak perlu patch pihak ketiga lagi. Semua command saya uji di Ubuntu 24.04 per Juli 2026.

1. Kenapa HTTP/3 dan QUIC Layak Diusahakan

Sebelum masuk ke command, penting paham apa yang lo dapat. HTTP/3 bukan sekadar "HTTP/2 tapi lebih baru" — dia ganti transport layer dari TCP ke QUIC (UDP). Implikasinya besar:

• Tidak ada head-of-line blocking — di HTTP/2 (TCP), satu paket hilang menahan semua stream. Di QUIC, stream independen; satu hilang tidak mengganggu yang lain.
• Handshake lebih cepat — QUIC menggabungkan handshake transport dan TLS 1.3, jadi koneksi baru butuh lebih sedikit round-trip. Ada juga 0-RTT resumption untuk koneksi ulang.
• Connection migration — koneksi QUIC diidentifikasi oleh connection ID, bukan IP+port. Jadi saat user pindah dari WiFi ke mobile, koneksi tidak putus.
• Lebih baik di packet loss — kondisi khas jaringan mobile Indonesia. QUIC tetap responsif saat TCP sudah megap-megap.

Untuk static site yang diakses banyak user mobile (mayoritas traffic Indonesia adalah mobile), manfaatnya nyata. Ini bukan optimasi kosmetik.

2. Prasyarat

Yang lo butuhkan:

• VPS Ubuntu 22.04 atau 24.04 dengan akses root/sudo. Saya pakai VPS kecil 1 vCPU/1GB RAM — lebih dari cukup untuk static site.
• Domain yang sudah diarahkan (A record) ke IP VPS lo.
• Nginx mainline 1.25+ (untuk QUIC native). Repo default Ubuntu mungkin versi lama, jadi kita pakai repo resmi Nginx.

Untuk pemilihan VPS-nya sendiri, kalau lo belum punya, saya sudah menulis perbandingan VPS untuk developer Indonesia yang bisa jadi panduan memilih provider dengan latensi terbaik ke Indonesia.

3. Install Nginx Mainline dengan QUIC

Ubuntu 24.04 repo punya Nginx 1.24, yang belum support QUIC native. Kita perlu Nginx mainline dari repo resmi. Pertama, tambah repo Nginx:

curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu noble nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install -y nginx

Verifikasi versi dan dukungan QUIC:

nginx -v
nginx -V 2>&1 | grep -o with-http_v3_module

Kalau output terakhir menampilkan with-http_v3_module, lo siap. Nginx dari repo resmi mainline sudah dikompilasi dengan modul HTTP/3 bawaan.

4. Setup Static Site Dasar

Buat direktori untuk file situs lo dan taruh konten di sana:

sudo mkdir -p /var/www/mysite
echo "<h1>Halo dari HTTP/3</h1>" | sudo tee /var/www/mysite/index.html
sudo chown -R www-data:www-data /var/www/mysite

Untuk static site generator seperti Astro, Hugo, atau Eleventy, lo tinggal copy hasil build (folder dist atau public) ke /var/www/mysite. Saya sendiri menjalankan beberapa situs Astro dengan cara ini — build lokal, rsync ke VPS.

5. Dapatkan Sertifikat TLS dengan certbot

HTTP/3 WAJIB pakai TLS (QUIC tidak support plaintext). Jadi kita butuh sertifikat TLS dulu. Pakai Let's Encrypt via certbot:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d mysite.com -d www.mysite.com

Certbot akan otomatis mengedit config Nginx untuk SSL. Setelah sertifikat terpasang, kita modifikasi config untuk menambah HTTP/3. Pendekatan certbot + Let's Encrypt ini sama dengan yang saya detailkan di panduan TLS Let's Encrypt self-hosted — bedanya di sini kita tambah layer QUIC di atasnya.

6. Konfigurasi Nginx untuk HTTP/3 (QUIC)

Ini inti tutorialnya. Edit server block lo (/etc/nginx/conf.d/mysite.conf atau yang dibuat certbot). Konfigurasi lengkap yang saya pakai:

server {
    listen 80;
    listen [::]:80;
    server_name mysite.com www.mysite.com;
    return 301 https://mysite.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name mysite.com www.mysite.com;

    ssl_certificate     /etc/letsencrypt/live/mysite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    root /var/www/mysite;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

# HTTP/3 / QUIC listener
server {
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    http3 on;
    server_name mysite.com www.mysite.com;

    ssl_certificate     /etc/letsencrypt/live/mysite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
    ssl_protocols TLSv1.3;

    root /var/www/mysite;
    index index.html;

    # Beri tahu browser bahwa HTTP/3 tersedia
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        try_files $uri $uri/ =404;
    }
}

Beberapa poin penting dari config ini:

• listen 443 quic reuseport — mengaktifkan QUIC di port 443. Flag reuseport penting untuk performa multi-worker (cukup taruh di satu server block quic).
• http3 on; — mengaktifkan HTTP/3 di server block ini.
• Alt-Svc header — ini krusial. Browser tidak akan pakai HTTP/3 kecuali server mengiklankannya via header Alt-Svc. Header ini bilang "hei browser, saya support h3 di port 443".
• TLSv1.3 untuk QUIC — QUIC mensyaratkan TLS 1.3, jadi server block quic cuma perlu TLSv1.3.

Strategi "dual listener" ini (TCP untuk HTTP/1.1+HTTP/2, UDP untuk HTTP/3) adalah pendekatan yang direkomendasikan. Browser akan fallback ke TCP kalau QUIC diblokir (beberapa jaringan korporat/firewall memblokir UDP 443).

7. Buka Port UDP 443 di Firewall

Ini langkah yang paling sering bikin orang bingung "kok HTTP/3 tidak jalan". QUIC pakai UDP port 443, bukan TCP. Kalau firewall lo cuma buka TCP 443, HTTP/3 tidak akan pernah connect.

sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw reload
sudo ufw status

Pastikan di output ufw status ada kedua baris: 443/tcp ALLOW dan 443/udp ALLOW. Kalau lo pakai cloud provider dengan security group tambahan (AWS, GCP), buka juga UDP 443 di sana.

8. Test dan Reload Nginx

Sebelum reload, selalu test config:

sudo nginx -t
sudo systemctl reload nginx

Kalau nginx -t mengembalikan syntax is ok dan test is successful, reload aman dilakukan. Reload (bukan restart) membuat koneksi yang sedang berjalan tidak terputus.

9. Verifikasi HTTP/3 Benar-Benar Jalan

Jangan cuma percaya config — verifikasi. Ini bagian yang sesuai prinsip saya: tidak ada klaim "sukses" tanpa bukti. Beberapa cara:

# Cek header Alt-Svc (pakai curl dengan HTTP/2)
curl -sI https://mysite.com | grep -i alt-svc

# Test QUIC langsung (butuh curl dengan HTTP/3 support)
curl --http3 -I https://mysite.com

Untuk verifikasi paling meyakinkan, buka situs lo di Chrome/Firefox, buka DevTools → Network tab, dan lihat kolom "Protocol". Kalau situs lo diakses via HTTP/3, kolom itu akan menampilkan h3. Pertama kali load mungkin masih h2 (browser perlu melihat header Alt-Svc dulu), tapi refresh kedua biasanya sudah h3.

Lo juga bisa pakai tool online seperti http3check.net atau cdn77 http3 test untuk verifikasi dari perspektif eksternal. Selalu verifikasi dari dua arah — dari server (curl) dan dari browser/eksternal — sebelum menyimpulkan HTTP/3 benar-benar aktif.

10. Optimasi Tambahan untuk Static Site

Sekarang HTTP/3 sudah jalan, beberapa optimasi tambahan yang saya selalu terapkan untuk static site:

# Di dalam server block, tambah:
gzip on;
gzip_types text/css application/javascript image/svg+xml application/json;
gzip_min_length 1024;

# Cache untuk aset statis
location ~* .(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

# Security headers
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

Perhatikan: add_header di level location akan menimpa header di level server, termasuk Alt-Svc. Jadi kalau lo tambah add_header di location tertentu, pastikan Alt-Svc tetap ikut (pakai always dan sertakan di location yang relevan, atau gunakan modul headers-more). Ini bug halus yang sering bikin Alt-Svc hilang dan HTTP/3 berhenti diiklankan.

Untuk monitoring apakah situs tetap up setelah semua perubahan ini, saya jalankan Uptime Kuma self-hosted yang nge-ping situs tiap menit dan alert kalau down. Murah meriah tapi menyelamatkan saya beberapa kali.

11. Troubleshooting Umum

Masalah yang paling sering muncul dan solusinya:

• HTTP/3 tidak pernah connect — 90% kasus karena UDP 443 belum dibuka di firewall/security group. Cek ufw status dan cloud firewall.
• Browser tetap pakai h2 — header Alt-Svc tidak terkirim. Cek dengan curl -sI. Biasanya karena add_header di location menimpa Alt-Svc.
• nginx -t error "unknown directive http3" — Nginx versi terlalu lama. Pastikan pakai mainline 1.25+ dari repo resmi, bukan repo Ubuntu.
• reuseport warning — flag reuseport cuma boleh ada di satu server block quic. Taruh di satu tempat saja.

12. Kapan HTTP/3 Belum Perlu Jadi Prioritas

Jujur saja, HTTP/3 bukan obat untuk semua masalah performa. Kalau situs lo lambat karena gambar yang tidak dikompresi, JavaScript yang membengkak, atau server yang under-spec, mengaktifkan QUIC tidak akan banyak membantu. Bereskan dulu fundamental performa — optimasi gambar ke WebP, lazy-load aset, minify CSS/JS, dan pastikan TTFB server rendah. HTTP/3 adalah lapisan penyempurna di atas fondasi yang sudah sehat, bukan pengganti fondasi itu.

Untuk situs dengan mayoritas user desktop di jaringan stabil, manfaat HTTP/3 juga lebih kecil dibanding untuk user mobile di jaringan tidak stabil. Tapi karena setup-nya sekarang sudah mudah dan tidak ada downside berarti (ada fallback TCP otomatis), mengaktifkannya tetap worthwhile sebagai future-proofing. Anggap ini investasi murah yang bikin situs lo siap saat adopsi HTTP/3 makin meluas.

Kesimpulan

Deploy static site dengan HTTP/3/QUIC di Nginx tidak sesulit yang dibayangkan — sejak Nginx mainline support QUIC native, tidak perlu lagi patch pihak ketiga. Kuncinya ada di tiga hal yang sering terlewat: pakai Nginx mainline 1.25+, buka UDP 443 di firewall, dan pastikan header Alt-Svc terkirim. Setelah itu, situs lo dapat manfaat koneksi yang lebih cepat dan tahan packet loss — sangat relevan untuk mayoritas user mobile Indonesia. Mulai dari dual listener (TCP + QUIC) supaya ada fallback, verifikasi dari browser dan curl sebelum klaim sukses, dan tambah optimasi caching + security headers. Dengan setup ini, static site lo tidak cuma cepat, tapi juga modern dan siap untuk masa depan web.