Tình huống
Bạn đã cấu hình port forwarding trên router, trỏ vào IP nội bộ của server, rồi thử kết nối từ bên ngoài — nhưng không thấy gì. Connection refused, timeout, hoặc kết nối cứ treo mãi. Dịch vụ chạy hoàn toàn bình thường trong mạng LAN, nhưng không có gì từ bên ngoài vào được.
Phần bực bội nhất là: mọi thứ trông đều đúng trong trang quản trị router. Rule đã có. IP đúng rồi. Vậy mà vẫn không hoạt động. Dưới đây là cách tìm ra đúng chỗ bị hỏng.
Bước 1: Xác nhận dịch vụ đang thực sự lắng nghe
Chưa cần động đến router. Trước tiên, hãy chắc chắn ứng dụng của bạn đang lắng nghe đúng địa chỉ và cổng.
# Trên Linux/macOS
ss -tlnp | grep 8080
# Hoặc dùng netstat
netstat -tlnp | grep 8080
# Windows
netstat -ano | findstr :8080
Kết quả mong muốn sẽ trông như thế này:
tcp 0.0.0.0:8080 LISTEN 12345/node
Thấy 127.0.0.1:8080 thay vì 0.0.0.0:8080? Điều đó có nghĩa là dịch vụ chỉ chấp nhận kết nối nội bộ — traffic từ router bị loại bỏ trước khi kịp đến ứng dụng. Hãy sửa cấu hình ứng dụng để bind vào 0.0.0.0 hoặc interface LAN cụ thể của bạn.
Bước 2: Kiểm tra trong mạng nội bộ trước khi đổ lỗi cho router
Từ một thiết bị khác trong cùng mạng LAN, thử kết nối trực tiếp vào IP nội bộ của server:
# Từ máy khác trong cùng LAN
curl http://192.168.1.100:8080
# Hoặc chỉ kiểm tra kết nối TCP
nc -zv 192.168.1.100 8080
Nếu bước này thất bại, bạn đang có vấn đề nội bộ — firewall hoặc cấu hình dịch vụ sai. Hãy khắc phục ở đây trước. Không có lý do gì để debug router nếu traffic thậm chí không vào được server từ bên trong.
Bước 3: Kiểm tra kỹ rule port forwarding trên router
Đăng nhập vào router (thường là 192.168.1.1 hoặc 192.168.0.1) và kiểm tra từng trường một:
- External port: cổng mà client bên ngoài kết nối vào
- Internal IP: IP nội bộ tĩnh của server — không phải IP do DHCP cấp có thể thay đổi
- Internal port: cổng mà ứng dụng thực sự lắng nghe (có thể khác external port)
- Protocol: TCP, UDP, hoặc cả hai — web server cần TCP; game server có thể cần UDP
- Rule đã được bật: một số router cho phép lưu rule ở trạng thái tắt
Cái bẫy phổ biến nhất ở đây là IP bị thay đổi. DHCP cấp cho server địa chỉ 192.168.1.105 tuần trước, rồi gán lại thành 192.168.1.112 sau khi khởi động lại — lúc này rule forwarding đang trỏ sai máy. Hãy đặt IP tĩnh trên server, hoặc dùng DHCP reservation trên router để server luôn nhận cùng một địa chỉ.
Bước 4: Kiểm tra firewall trên chính server
Port forwarding đưa traffic đến máy của bạn. Firewall nội bộ vẫn có thể âm thầm chặn traffic sau đó. Kiểm tra và mở cổng:
# UFW (Ubuntu/Debian)
sudo ufw status
sudo ufw allow 8080/tcp
# firewalld (CentOS/RHEL/Fedora)
sudo firewall-cmd --list-ports
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
# iptables (trực tiếp)
sudo iptables -L INPUT -n | grep 8080
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
# Windows Defender Firewall
netsh advfirewall firewall add rule name="Allow 8080" protocol=TCP dir=in localport=8080 action=allow
Bước 5: Kiểm tra từ mạng bên ngoài thực sự
Kiểm tra từ trong mạng LAN của bạn sẽ không có tác dụng — hầu hết router gia đình không hỗ trợ NAT hairpinning, vì vậy bạn sẽ nhận được kết quả âm tính giả. Hãy dùng điện thoại qua mạng di động, một máy chủ cloud giá rẻ, hoặc một công cụ kiểm tra cổng trực tuyến.
# Lấy IP public của bạn trước
curl ifconfig.me
# hoặc
curl https://api.ipify.org
# Sau đó kiểm tra từ bên ngoài
curl http://YOUR_PUBLIC_IP:8080
nc -zv YOUR_PUBLIC_IP 8080
Đọc kỹ thông báo lỗi. Timeout nghĩa là một firewall đang chặn gói tin phía trước — firewall của router, ISP, hoặc firewall của hệ điều hành. Connection refused nghĩa là traffic đã đến được máy nhưng có gì đó đang từ chối ở tầng ứng dụng.
Bước 6: Tìm Double NAT
Bạn có combo modem/router từ ISP, cộng thêm router riêng của bạn cắm sau nó? Bạn đang bị double NAT. Forwarding port trên router của bạn chỉ đưa traffic đến cổng WAN của router đó — thiết bị ISP vẫn chặn traffic từ internet.
# Theo dõi đường đi ra ngoài
traceroute 8.8.8.8
# Hai bước nhảy với IP private (ví dụ: 192.168.0.1 rồi đến 10.0.0.1)?
# Đó là double NAT.
Cách xử lý gọn nhất là đặt thiết bị ISP vào chế độ bridge để nó ngừng thực hiện NAT hoàn toàn. Nếu không, bạn cần cấu hình port forwarding trên cả hai thiết bị — modem ISP forward đến WAN IP của router của bạn, và router của bạn forward đến server. Gọi cho ISP nếu trang quản trị của modem bị khóa.
Bước 7: Kiểm tra CGNAT
Cái này hay khiến nhiều người bất ngờ. Nhiều ISP — đặc biệt là các nhà mạng di động/4G — dùng Carrier-Grade NAT, trong đó IP "public" của bạn thực ra được chia sẻ với hàng nghìn khách hàng khác. Bạn thực sự không thể nhận kết nối từ bên ngoài. Port forwarding sẽ không hoạt động được.
# So sánh hai thứ này:
curl ifconfig.me # IP public bề ngoài của bạn
# so với WAN IP của router trong trang quản trị
# Nếu chúng khác nhau, bạn đang ở sau CGNAT.
Nếu WAN IP của router thuộc bất kỳ dải nào dưới đây, điều đó xác nhận bạn đang bị CGNAT:
100.64.0.0/10 (dải CGNAT, RFC 6598)
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Các lựa chọn: yêu cầu ISP cấp IP public thực (một số cấp miễn phí, một số tính phí khoảng 5–10 USD/tháng), dùng dịch vụ VPN có hỗ trợ port forwarding (Mullvad, AirVPN), hoặc bỏ qua vấn đề này hoàn toàn bằng tunnel như Cloudflare Tunnel hoặc ngrok.
Xác nhận kết quả
Sau khi áp dụng các bước khắc phục, hãy kiểm tra từ mạng bên ngoài thực sự:
# Từ mạng di động hoặc máy chủ cloud
curl -v http://YOUR_PUBLIC_IP:8080
# Mong muốn: nhận được HTTP response từ ứng dụng của bạn
# Không tốt: "Connection refused" hoặc kết nối bị treo
Hãy kiểm tra thêm log firewall/NAT của router — hầu hết router đều ghi lại xem các gói tin có khớp với rule forwarding hay không, giúp bạn biết chính xác traffic đi được đến đâu.
Mẹo thêm
Khi tìm hiểu các vấn đề về NAT và subnet, tôi thường mở sẵn Subnet Calculator tại ToolCraft trong một tab. Công cụ này rất hữu ích để nhanh chóng xác nhận IP LAN của server có thực sự nằm trong dải mạng nội bộ của router hay không — rất dễ tính nhầm subnet mask khi bạn đang bực bội. Chạy hoàn toàn trên trình duyệt, không upload dữ liệu.
Một vài kiểm tra nhanh trước khi lao vào cấu hình router:
- Xác nhận server nằm cùng subnet với interface LAN của router (ví dụ: cả hai đều thuộc 192.168.1.0/24)
- Kiểm tra default gateway của server trỏ đúng vào router — không phải một static route còn sót lại
- Chạy
ip route(Linux) hoặcroute print(Windows) để đảm bảo traffic không lén ra qua một interface khác
Phòng tránh
- Luôn đặt IP tĩnh hoặc DHCP reservation cho bất kỳ server nào bạn forward port — IP thay đổi sẽ phá vỡ các rule của bạn một cách lặng lẽ
- Ghi chép lại các rule port forwarding của bạn ở đâu đó. Reset router và cập nhật firmware sẽ xóa sạch chúng, và bạn sẽ quên mất những gì đã cấu hình sáu tháng trước
- Để truy cập từ xa ổn định lâu dài, WireGuard VPN hiệu quả hơn việc mở từng port riêng lẻ — khó bị tấn công hơn, dễ kiểm soát hơn, và hoạt động được trên cả các mạng hạn chế
- Luôn kiểm tra từ bên ngoài mạng của bạn sau mỗi lần thay đổi. Sự cố NAT loopback sẽ cho kết quả sai lệch khi bạn kiểm tra từ cùng một mạng LAN