Noctis
ENID
Client area Pesan server

Cara Menguji Koneksi FiveM dengan MTR, Ping dan Packet Capture

Panduan teknis mengumpulkan bukti masalah jaringan FiveM: menjalankan MTR dan WinMTR, membedakan loss nyata dari rate limit ICMP, menguji port 30120 dengan TCP dan UDP, packet capture dengan tcpdump, dan template laporan lintas ISP.

6 menit baca FiveM

"Server lag" adalah keluhan yang paling sering dan paling sulit ditindaklanjuti. Lag bisa berarti FPS rendah di PC pemain, server hitch, ping tinggi, jitter, atau packet loss. Masing-masing punya penyebab dan solusi berbeda. Tanpa data, owner server biasanya menebak: upgrade hardware, pindah hosting, atau membeli proxy, lalu kecewa karena masalahnya tidak hilang.

Panduan ini untuk owner, sysadmin, dan developer yang ingin mengumpulkan bukti. Kita akan memakai ping, MTR, tes TCP/UDP ke port 30120, dan packet capture, lalu menyusunnya menjadi laporan yang bisa dipakai untuk mengambil keputusan atau dikirim ke penyedia jaringan.

Pisahkan dulu jenis masalahnya

Sebelum membuka terminal, pastikan masalahnya memang di jaringan:

  • FPS rendah (angka FPS turun, game patah-patah walau sendirian di area sepi) → masalah PC atau script client. Bukan jaringan.
  • Server hitch (console FXServer menampilkan peringatan hitch, semua pemain merasakan lag bersamaan) → masalah performa server. Lihat cara mengatasi server hitch warning.
  • Ping tinggi, jitter, atau packet loss (rubber banding, kendaraan melompat, hanya dialami sebagian pemain atau ISP tertentu) → kemungkinan jaringan. Lanjutkan dengan panduan ini.

1. Ping: cepat, tapi terbatas

Ping adalah tes paling sederhana:

# Windows
ping -n 100 IP_SERVER

# Linux / macOS
ping -c 100 IP_SERVER

Perhatikan tiga angka: rata-rata (avg), variasi (mdev di Linux, atau selisih min dan max di Windows), dan persentase loss.

Keterbatasannya: ping memakai ICMP, sedangkan FiveM memakai TCP dan UDP di port 30120. Sebagian jaringan memperlakukan ICMP dengan prioritas rendah atau membatasinya. Selain itu, banyak server dan firewall memblokir ICMP sepenuhnya, sehingga ping "timeout" tidak berarti server tidak bisa dijangkau. Pakai ping sebagai indikasi awal, bukan kesimpulan.

2. MTR: melihat setiap hop

MTR menggabungkan traceroute dan ping: ia mengirim paket ke setiap router di sepanjang rute secara terus-menerus, lalu menampilkan loss dan latency per hop.

Di Linux

sudo apt install mtr-tiny
mtr -rwzbc 200 IP_SERVER
  • -r mode laporan (berhenti setelah selesai)
  • -w laporan lebar, hostname tidak dipotong
  • -z tampilkan nomor AS tiap hop
  • -b tampilkan hostname dan IP
  • -c 200 kirim 200 paket per hop

Di Windows

Pakai WinMTR: masukkan IP server, klik Start, biarkan berjalan minimal 3–5 menit, lalu Export TEXT. Alternatif bawaan Windows adalah pathping IP_SERVER, yang lebih lambat tapi memberi hasil serupa.

Contoh hasil dan cara membacanya

Berikut contoh hasil MTR (ilustrasi, bukan pengukuran nyata):

HOST                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1               0.0%   200    1.1   1.3   0.9   4.2   0.4
 2. 10.x.x.x                  0.0%   200    4.8   5.2   3.9  12.1   1.1
 3. isp-core-1.example        0.0%   200    6.1   6.8   5.2  15.3   1.4
 4. isp-border-1.example     45.0%   200    9.2   9.9   8.1  22.4   2.0
 5. transit-1.example         0.0%   200   18.3  19.1  17.8  30.2   1.9
 6. ???                      100.0   200    0.0   0.0   0.0   0.0   0.0
 7. IP_SERVER                 0.0%   200   19.4  20.0  18.9  28.7   1.6

Cara membacanya:

  • Hop 4 menunjukkan 45% loss, tapi hop 5 dan 7 0%. Ini hampir pasti bukan masalah. Router membatasi berapa banyak balasan ICMP yang ia kirim (ICMP rate limiting) karena membalas ping bukan tugas utamanya. Paket yang melewati router itu tetap diteruskan dengan normal.
  • Hop 6 menunjukkan ??? dan 100% loss. Router tersebut tidak membalas ICMP sama sekali. Selama hop sesudahnya normal, ini juga bukan masalah.
  • Aturan utama: loss nyata adalah loss yang dimulai di satu hop dan berlanjut sampai tujuan. Kalau hop 4 menunjukkan 5% loss dan semua hop setelahnya termasuk tujuan juga sekitar 5%, kemungkinan besar ada masalah di hop 4 atau link sebelumnya.
  • Latency juga begitu. Lonjakan di satu hop tengah yang tidak berlanjut hanya berarti router itu lambat membalas ICMP. Lonjakan yang bertahan sampai tujuan adalah tambahan latency nyata.
  • StDev adalah indikator jitter. StDev tinggi di tujuan berarti latency tidak stabil, yang di FiveM terasa sebagai rubber banding.

Satu catatan lagi: MTR hanya menunjukkan rute dari kamu ke server. Rute balik bisa berbeda. Kalau memungkinkan, jalankan juga MTR dari server ke IP publik pemain.

3. Tes dengan protokol yang dipakai FiveM

Karena ICMP bisa diperlakukan berbeda, uji juga dengan TCP dan UDP ke port 30120.

MTR dengan TCP

sudo mtr -rwzbc 200 -T -P 30120 IP_SERVER

Mode TCP mengirim paket SYN ke port 30120. FXServer akan membalas, jadi hop tujuan memberi hasil yang bisa dipercaya untuk port game.

MTR dengan UDP

sudo mtr -rwzbc 200 -u -P 30120 IP_SERVER

Mode UDP berguna untuk melihat apakah rute UDP berbeda dari ICMP. Tapi hati-hati membaca hop terakhir: FXServer tidak membalas paket UDP sembarang, jadi tujuan bisa terlihat 100% loss walaupun koneksi game normal. Fokus pada hop-hop sebelum tujuan, dan pakai mode TCP untuk mengukur tujuannya.

Cek port terbuka dari sisi pemain

# Windows PowerShell
Test-NetConnection IP_SERVER -Port 30120

# Linux / macOS
nc -vz IP_SERVER 30120

Kalau TCP 30120 tidak bisa dijangkau sama sekali, masalahnya bukan lag, melainkan firewall atau server mati. Lihat juga cara mengatasi FiveM gagal connect.

4. Packet capture di sisi server

MTR mengukur rute dengan paket uji. Packet capture melihat trafik game yang sebenarnya. Ini berguna untuk menjawab pertanyaan seperti "apakah paket dari pemain X benar-benar sampai ke server?" atau "apakah ada lonjakan trafik aneh di jam tertentu?".

Capture dengan tcpdump

# lihat interface yang dipakai
ip -br addr

# capture trafik UDP 30120 dari satu pemain, 5 menit
sudo timeout 300 tcpdump -i eth0 -nn -s 128 udp port 30120 and host IP_PEMAIN -w pemain.pcap

# capture semua trafik 30120, dibatasi 100 MB per file, maksimal 5 file
sudo tcpdump -i eth0 -nn -s 128 port 30120 -C 100 -W 5 -w fivem.pcap

-s 128 hanya menyimpan 128 byte awal tiap paket, cukup untuk header dan menjaga ukuran file kecil. Jangan biarkan capture tanpa batas berjalan di server produksi; disk bisa penuh.

Analisis di Wireshark

Buka file .pcap di Wireshark, lalu:

  • Filter udp.port == 30120 && ip.addr == IP_PEMAIN untuk mengisolasi satu pemain.
  • Statistics → I/O Graphs: lihat apakah ada celah (beberapa detik tanpa paket) saat pemain melaporkan lag. Celah di arah masuk berarti paket dari pemain tidak sampai ke server.
  • Statistics → Conversations → UDP: bandingkan jumlah paket masuk dan keluar per pemain.

Packet capture paling kuat jika dilakukan di dua sisi sekaligus: di server dan di PC pemain (Wireshark di Windows). Kalau pemain mengirim paket yang tidak pernah muncul di capture server, paket hilang di perjalanan, dan itu bukti packet loss yang tidak bisa dibantah oleh hasil ICMP.

Kalau server berada di balik proxy, ingat bahwa di capture origin semua pemain muncul dengan IP proxy. Capture di sisi proxy (jika kamu punya akses) atau filter berdasarkan port sumber.

5. Kumpulkan data lintas ISP dan waktu

Satu tes dari satu orang hampir tidak pernah cukup. Susun pengumpulan data seperti ini:

  1. Pilih 3–5 pemain dari ISP dan kota berbeda.
  2. Minta mereka menjalankan MTR/WinMTR 200 paket di dua waktu: jam sepi dan jam ramai.
  3. Minta mereka memakai kabel LAN jika memungkinkan, atau mencatat bahwa mereka memakai Wi-Fi.
  4. Di saat yang sama, jalankan MTR dari server ke IP publik mereka.
  5. Catat jam kejadian lag yang dilaporkan, lalu cocokkan dengan grafik server (CPU, hitch, bandwidth). Kalau kamu sudah punya monitoring, lihat Prometheus dan Grafana untuk FiveM.

Kalau masalah hanya muncul dari satu ISP di jam ramai, kemungkinan besar penyebabnya rute atau kepadatan. Penjelasan mekanismenya ada di kenapa ping FiveM tinggi dari IndiHome.

Template laporan

Gunakan format ini saat mengirim laporan ke penyedia hosting, ISP, atau tim kamu sendiri:

Ringkasan
- Gejala       : rubber banding / ping tinggi / disconnect
- Mulai        : 2026-10-20, sekitar 20.00 WIB
- Terdampak    : pemain dari ISP A (Bandung, Surabaya); ISP B normal
- Server       : IP_SERVER, port 30120 TCP+UDP, lokasi Jakarta

Bukti
- MTR ICMP pemain ISP A, jam 09.00 dan 21.00 (lampiran)
- MTR TCP 30120 pemain ISP A, jam 21.00 (lampiran)
- MTR dari server ke IP pemain ISP A (lampiran)
- Pembanding: MTR pemain ISP B, jam 21.00 (lampiran)
- Grafik CPU dan hitch server di jam yang sama: normal

Temuan
- Loss mulai di hop N (hostname, AS) dan berlanjut sampai tujuan
- Latency naik dari ~X ms ke ~Y ms hanya di jam ramai

Permintaan
- Mohon dicek kepadatan atau rute di hop N

Laporan dengan data seperti ini jauh lebih mungkin ditindaklanjuti daripada "server lag dari ISP A".

Kesalahan yang sering terjadi

  • Menyimpulkan dari satu hop tengah. Loss di hop tengah yang tidak berlanjut hampir selalu rate limiting ICMP.
  • Tes terlalu singkat. 10 paket tidak cukup untuk melihat loss 1–2%. Pakai minimal 100–200 paket.
  • Tes lewat Wi-Fi tanpa dicatat. Jitter dari Wi-Fi rumah bisa disangka masalah ISP.
  • Hanya tes ICMP. Selalu tambahkan tes TCP ke port 30120.
  • Mengubah banyak hal sekaligus. Pindah hosting, pasang proxy, dan update resource dalam satu hari membuat kamu tidak tahu mana yang berpengaruh.

FAQ

Berapa packet loss yang masih wajar untuk FiveM?

Idealnya 0% di tujuan. Loss kecil yang konsisten pun bisa terasa sebagai rubber banding karena trafik gameplay berjalan terus-menerus. Yang penting adalah apakah loss terjadi di tujuan, bukan hanya di hop tengah.

Apakah hasil MTR dari server ke pemain bisa dipercaya kalau router rumah pemain memblokir ICMP?

Hop terakhir mungkin tidak membalas, tapi hop-hop sebelumnya tetap menunjukkan kondisi rute balik sampai jaringan ISP pemain. Itu sudah cukup untuk melihat di mana latency atau loss mulai muncul.

Apakah saya perlu packet capture untuk setiap keluhan?

Tidak. Mulai dari MTR. Packet capture dipakai saat MTR tidak memberi jawaban jelas, atau saat kamu butuh bukti bahwa paket game benar-benar hilang.

Setelah tahu masalahnya di rute, apa yang bisa saya lakukan?

Laporkan ke ISP atau penyedia hosting dengan data di atas, pertimbangkan lokasi server yang punya rute lebih baik ke mayoritas pemain, atau uji titik masuk alternatif seperti IP proxy. Panduan lanjutan ada di cara mengatasi packet loss FiveM.

Penutup

Data mengalahkan tebakan. Dengan ping, MTR dalam mode ICMP dan TCP, packet capture di kedua sisi, dan tes lintas ISP di jam berbeda, kamu bisa membedakan masalah PC, server, jaringan rumah, dan rute ISP. Baru setelah itu solusi bisa dipilih dengan tepat.

Sebagai keterbukaan: Noctis menjual IP Proxy dengan titik masuk di Jakarta atau Singapore, yang bisa menjadi rute alternatif ke servermu. Proxy menambah satu hop, jadi gunakan langkah di artikel ini untuk membandingkan rute langsung dan rute lewat proxy sebelum memutuskan.

Baca juga

Semua tulisan
Gabung Discord