Cloudflare → nginx-lb (V1) → 5 server nội bộ — bản vẽ tham chiếu hiện trạng production. Kết luận chính và điểm cần xử lý: mục 03. Chi tiết từng tầng: Deep Dive hạ tầng.
HTTP :80 origin-pull — xem card "Realip / Cloudflare trust" bên dưới
Lưu ý vận hành: V2 và V3 dùng chung hostname mặc định ubuntu-8gb-ash-1 (Hetzner đặt theo spec, không phải tên định danh duy nhất). Không dùng hostname để nhận diện server khi SSH — chỉ IP mới chắc chắn: V2 = 10.0.0.4 / 178.156.166.189, V3 = 10.0.0.2 / 178.156.211.239.
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
… (15 dải CIDR của Cloudflare) …
set_real_ip_from 131.0.72.0/22;
real_ip_header CF-Connecting-IP;proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
proxy_set_header CF-Connecting-IP $http_cf_connecting_ip;
proxy_set_header CF-Ray $http_cf_ray;upstream backend {
least_conn;
server 10.0.0.5:3001 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.5:3002 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.5:3003 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.5:3004 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.4:3001 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.4:3002 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.4:3003 weight=1 max_fails=3 fail_timeout=30s;
server 10.0.0.4:3004 weight=1 max_fails=3 fail_timeout=30s;
}proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;worker_processes auto;
worker_connections 1024;
keepalive_timeout 65;
gzip on;
gzip_comp_level 6;
include conf.d/*.conf;image: nginx:alpine
container_name: nginx-lb
restart: always
network_mode: host
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d:ronetwork_mode: host là lý do nginx gọi thẳng được 10.0.0.x mà không cần khai báo network Docker riêng — đồng thời cũng là lý do nếu chạy 2 bản trên 2 server thì KHÔNG xung đột cổng lẫn nhau (mỗi cái độc lập trên host riêng).firewall-ssh22/tcp ← Any IPv4, Any IPv6
icmp ← Any IPv4, Any IPv6
80/tcp ← 5/15 dải Cloudflare
(thiếu 10 dải nginx đang tin)
443/tcp ← 15/15 dải Cloudflare
(nginx không listen 443)set_real_ip_from (lọc ở tầng application). 2 tầng đang lệch nhau ở cổng 80: firewall chặt hơn nginx (5 dải so với 15), nên có thể chặn nhầm traffic Cloudflare thật. firewall-ssh là firewall duy nhất trong project và không có rule nào cho 6379/5432/9200/… — các port data default-deny từ Internet.Điểm cần xử lý (Hetzner Firewall firewall-ssh, áp cho cả 5 server): rule :80 chỉ whitelist 5/15 dải Cloudflare trong khi nginx tin 15 dải qua set_real_ip_from — request thật qua PoP thuộc 10 dải thiếu bị DROP trước khi tới nginx (sửa trên Console, bước 0A của kế hoạch chuyển đổi); rule :22 mở cho toàn Internet (bước 0B); rule :443 có đủ 15/15 dải dù nginx không listen 443. Xem card ⑦ ở trên và rủi ro #13–14 trong Ha-Tang-Deep-Dive.html.
Kết luận chính: nginx-lb duy nhất trên V1 — SPOF của toàn hệ · frontend không nằm trong 5 server: 6 site (client, shop, agent, super-agent, admin, cashier) hosting trên Cloudflare Pages · các port data (6379/5432/9200/…) default-deny từ Internet · Dozzle (4/4) và RedisInsight báo unhealthy chỉ do healthcheck image sai — không phải sự cố. Kế hoạch xử lý: so-sanh-va-ke-hoach-chuyen-doi.html · kiến trúc đích: he-thong-dich.html.