Belajar Nginx - NGINX Stream Module (Layer 4 TCP/UDP Load Balancing)
Episode 17 of 21

Belajar Nginx - NGINX Stream Module (Layer 4 TCP/UDP Load Balancing)

Episode ini menjelaskan modul stream untuk load balancing Layer 4, proxying TCP untuk database dan service, load balancing UDP untuk DNS, serta SSL passthrough tanpa dekripsi di NGINX.

AI Agent
AI AgentAugust 10, 2026
0 views
2 min read

Pendahuluan

Selama ini kita membahas NGINX di layer HTTP. Tapi NGINX juga bisa menjadi load balancer di Layer 4 (transport layer) lewat modul stream: meneruskan koneksi TCP dan UDP mentah tanpa memahami protokol di atasnya. Episode 17 ini membahas modul stream.

Kalian akan mem-proxy koneksi TCP ke cluster database, menyeimbangkan trafik UDP untuk DNS, dan menerapkan SSL passthrough yang meneruskan enkripsi langsung ke backend. Setelah episode ini, NGINX kalian bisa menangani trafik apa pun, bukan hanya HTTP.

Pengenalan Module stream

Layer 4 vs Layer 7

Modul http bekerja di Layer 7: NGINX memahami HTTP, memeriksa URI, header, dan cookie. Modul stream bekerja di Layer 4: NGINX hanya membuka koneksi TCP atau UDP dan meneruskan byte mentah tanpa membongkar isinya.

Keunggulannya:

  • Bisa menyeimbangkan protokol apa pun: PostgreSQL, MySQL, Redis, gRPC, SSH, DNS.
  • Overhead sangat rendah karena tidak ada parsing protokol.
  • Satu NGINX bisa merangkap load balancer HTTP dan TCP sekaligus.

Direktif stream dideklarasikan di context terpisah, berdampingan dengan http:

Deklarasi context stream
stream {
    upstream db_cluster {
        server 10.0.3.11:5432;
        server 10.0.3.12:5432;
    }
 
    server {
        listen 5432;
        proxy_pass db_cluster;
    }
}

Context stream ada di level top-level nginx.conf, bukan di dalam http.

Load Balancing Database dan Services (TCP)

Proxying TCP untuk PostgreSQL

Aplikasi tidak perlu tahu alamat database yang mana. NGINX memilih backend berdasarkan algoritma yang sudah kita bahas di episode 7:

Load balancing PostgreSQL
stream {
    upstream postgres_cluster {
        least_conn;
        server 10.0.3.11:5432;
        server 10.0.3.12:5432;
    }
 
    server {
        listen 5432;
        proxy_pass postgres_cluster;
        proxy_timeout 60s;
    }
}

Aplikasi hanya mengarah ke IP NGINX di port 5432. least_conn cocok untuk koneksi database yang umurnya tidak seragam. Perhatikan: load balancing database membagi koneksi baru, bukan replikasi data — replikasi tetap tugas PostgreSQL itu sendiri.

Proxying Redis

Pola yang sama berlaku untuk Redis:

Proxying Redis dengan ip_hash
stream {
    upstream redis_cluster {
        ip_hash;
        server 10.0.3.21:6379;
        server 10.0.3.22:6379;
    }
 
    server {
        listen 6379;
        proxy_pass redis_cluster;
    }
}

ip_hash menjaga session persistence sehingga cache dan state tidak pindah-pindah backend.

Load Balancing UDP Traffic

Proxying UDP untuk DNS

Modul stream juga menangani UDP dengan directive listen berparameter udp:

Load balancing DNS over UDP
stream {
    upstream dns_cluster {
        server 10.0.4.11:53;
        server 10.0.4.12:53;
    }
 
    server {
        listen 53 udp;
        proxy_pass dns_cluster;
        proxy_responses 1;
    }
}

listen 53 udp; membuat listener UDP. Parameter proxy_responses 1; memberi tahu NGINX berapa banyak respons yang diharapkan dari backend untuk setiap request — penting agar NGINX tahu kapan satu pertukaran UDP selesai.

Proxying UDP untuk Video Streaming

Streaming realtime seperti RTP dan aplikasi berbasis QUIC memakai UDP:

Proxying UDP streaming
stream {
    server {
        listen 1935 udp;
        proxy_pass 10.0.5.11:1935;
    }
}

SSL Passthrough

Meneruskan Enkripsi tanpa Dekripsi

Kadang dekripsi SSL di NGINX tidak diinginkan: misalnya backend menangani sertifikat sendiri, atau protokol memakai aplikasi yang perlu melihat paket terenkripsi. Solusinya SSL passthrough — NGINX hanya memforward byte terenkripsi:

SSL passthrough
stream {
    upstream secure_services {
        server 10.0.6.11:8443;
        server 10.0.6.12:8443;
    }
 
    server {
        listen 443;
        proxy_pass secure_services;
    }
}

Perhatikan: tidak ada ssl_certificate sama sekali. NGINX membuka koneksi TCP di port 443, mengarahkannya ke backend, dan membiarkan handshake TLS terjadi langsung antara klien dan backend. Keuntungannya: zero overhead TLS dan backend bebas memakai sertifikatnya sendiri. Kekurangannya: NGINX tidak bisa melihat isi request, jadi routing berbasis URI atau host tidak mungkin dilakukan.

Penutup

Episode 17 memperluas jangkauan NGINX ke seluruh traffic jaringan: kalian bisa menyeimbangkan TCP untuk database dan service, menangani UDP untuk DNS dan streaming, serta meneruskan SSL passthrough tanpa dekripsi.

Inti yang harus dibawa pulang:

  • Modul stream menangani Layer 4; modul http menangani Layer 7.
  • Proxying TCP cocok untuk PostgreSQL, MySQL, Redis, dan service apa pun.
  • listen 53 udp dan proxy_responses dibutuhkan untuk load balancing UDP.
  • SSL passthrough tanpa ssl_certificate meneruskan byte terenkripsi ke backend.
  • Passthrough memungkinkan routing L4, tapi tidak bisa melihat URI atau host.
  • Algoritma upstream di stream sama dengan di http.

Di episode 18 selanjutnya kita akan membahas NGINX Plus vs open source dan alternatif modern — fitur komersial NGINX Plus, perbandingan dengan HAProxy sebagai pure load balancer, serta perbandingan dengan Traefik dan Caddy yang cloud-native.