Great Lotus — Kiến trúc End-to-End

Máy giao tiếp n8n B15

Hai node phát lệnh — C10 và C12

Cả hai đều là MQTT command emitter thuần: không import Playwright/PyAutoGUI, chỉ mqtt.connect → publish → (tuỳ chọn) chờ RES_.

Giao thức MQTT — hợp đồng bất biến

// REQUEST  node → worker
{
  "version": "great-lotus-v2",                       // hoặc great-lotus-pyauto-v1
  "action":  { "key":"mouse.click", "group":"MouseAction", "function":"click" },
  "inputs":  { "remote_port": {"type":"number","value":8888},
               "x": {"type":"number","value":320} },  // ô để TRỐNG bị loại khỏi payload
  "meta":    { "requestId":"a1b2c3d4e5f60718", "requestTopic":"WP2_PC176",
               "responseTopic":"RES_WP2_PC176", "waitForResponse":true,
               "responseTimeoutSec":60 }
}

// RESPONSE worker → node
{ "return":"OK"|"NG", "result":true, "error":"…", "data":{…},
  "meta":{ "requestId":"a1b2c3d4e5f60718" } }        // PHẢI echo đúng requestId

• action.function = khoá dispatch phía Python. Đổi nó ⇒ phá worker.
• return: "NG" ⇒ node ném lỗi, đọc chi tiết theo thứ tự error → message → data.error.
• Riêng image.wait_color: result === false cũng là fail dù return không NG.
• Worker phải echo meta.requestId — nếu không, node sẽ chấp nhận response đầu tiên bất kỳ ⇒ nhận nhầm khi chạy song song trên cùng topic.

Chương trình chạy trên worker

Application/APP_5_GPM_GREAT_LOTUS/App/2_GPM_Multi_Remote_Browser_Process_Manager_GUI/

Cấu hình worker *_config.json

Định tuyến đa session — _parse_route()

Một máy worker chạy nhiều trình duyệt cùng lúc. Mỗi session = một worker_key = một tiến trình con riêng.

⭐ Cổng ảo 127001 và chuỗi session

• remote_port = 127001 nghĩa là "session local" (gợi nhớ 127.0.0.1) — không phải cổng TCP. Chọn số ngoài dải 1..65535 để không bao giờ đụng cổng CDP thật.
• Giá trị cũ 0 vẫn được chấp nhận nhưng không dùng nữa vì 0 là falsy → dễ bị coi nhầm là "chưa nhập" khi đi qua expression n8n.
• Node luôn xuất cổng ra top-level output dưới CẢ HAI tên khoá: remote_debugging_port (tên C10) và remote_port (tên C12), cùng giá trị ⇒ nối chéo C10 ↔ C12 trong một workflow đều chạy.
• Ô Remote Port của action thường mặc định ={{$json.remote_debugging_port}} ⇒ cổng tự chảy xuôi chuỗi node.

[open_profile] ──► Client mở trình duyệt qua GPM, trả về cổng CDP
      │            C10 rút cổng từ response và GẮN vào output:
      ▼            json.remote_debugging_port = <port>
[mouse.click]  ──► ô remote_port mặc định ={{$json.remote_debugging_port}}
      │            → attach đúng phiên → click đúng cửa sổ
      ▼
[element.get_text] ─► tương tự, cùng session…

GPM Login — phần mềm quản lý profile

Anti-detect browser: mỗi profile = một danh tính số độc lập (fingerprint, cookie, cache riêng), chạy nhiều Chrome song song. Cổng 16813 cũng xuất hiện trong repo — phiên bản GPM khác nhau đổi cổng, luôn lấy từ gpm_base_url.

Giám sát — B34 GPM Fleet Monitor

Thiết kế đã chốt — Hybrid Storage & Decentralized Config

Nguồn: báo cáo UID_00001_profile_optimization_report.html — thiết kế cho quy mô 10.000 profile.

Tham số Chromium bắt buộc

// config.json nằm ở gốc mỗi profile
{ "profile_id": "profile_101", "status": "active",
  "cache_settings": { "current_cache_limit_mb": 50, "last_actual_cache_mb": 42.5 },
  "audit_logs": { "total_runs": 124, "last_run_time": "2026-07-19T18:12:00Z",
                  "last_run_machine": "CLIENT-PC-04", "last_run_duration_seconds": 320 } }

Sau mỗi lần chạy, tính lại hạn mức cache bằng AIMD (dùng gần chạm trần → +20MB, tối đa 100MB; dùng ít → giảm) rồi ghi đè config.json trước khi đóng gói.

Vì sao phải đóng gói .tar? — số đo quyết định

Profile 50MB, LAN ~40–50MB/s.

🟡 Trạng thái: CƠ CHẾ ĐÃ CÓ CÔNG CỤ THAM CHIẾU — CHƯA NỐI VÀO WORKER

Trong luồng chạy thật của worker, mắt xích "tải profile từ NAS" vẫn chưa được nối: grep toàn repo (APP_5, A12_PlayWright, A13_PyAutoGUI_Web, B05_GPM_Login_Manager) với smb|cifs|webdav|nas_|profile*.tar|temp_profiles không có một dòng nào. Thư viện Library/C02_NAS/nas.py chỉ là SSH tới NAS1 (172.16.10.201:222), không liên quan kho profile. Cái worker đang chạy thật vẫn chỉ là open_profile (mở profile có sẵn trên máy) và sync_master_profile_to_local_test_profile (copy master cục bộ).

⇒ Còn thiếu để thành production: (1) share đã tạo — còn tách quyền lotus_worker (rw) / lotus_ro (chỉ đọc) thay cho tài khoản admin; (2) gọi profile_store.pull trước open_profile và push sau khi đóng, ngay trong Process Manager của APP_5; (3) chính sách xử lý xung đột khi 2 máy cùng đụng một profile (xem cột "Đánh giá / rủi ro").

Khảo sát thực tế NAS2 từ HP1, qua VPN IPSec

Trên HP1 có sẵn mount.cifs và rsync. Worker là Windows ⇒ SMB là công dân hạng nhất.

⭐ ĐỀ XUẤT: dùng SMB3 (CIFS) làm kênh chính

Sáu lý do chọn SMB, theo thứ tự quan trọng

1. Đúng hình dạng của workload. Sau quyết định đóng gói .tar, mỗi lần chạy chỉ là 1 file lớn, đọc/ghi tuần tự — đúng thứ SMB3 làm tốt nhất (large MTU, multichannel, không bị phạt round-trip như random I/O). Con số 1.45s ở trên chính là đo trên SMB.
2. Không thêm dependency lên worker. Windows nói SMB bẩm sinh. File .bat bootstrap đã phải cài 12 gói pip; thêm webdavclient3/paramiko/smbprotocol là thêm bề mặt lỗi trên mọi máy worker, đổi lấy 0 lợi ích.
3. WebDAV trên NAS2 hiện đang TẮT. Chọn nó = phải bật package, mở cổng, xử lý chứng chỉ.
4. Đã có IPSec ⇒ dùng thẳng UNC \\172.16.20.201\<share> bằng IP LAN, không cần port-forward, không phụ thuộc DDNS động của WP2 (118.69.136.48 là IP động).
5. Ghi nguyên tử làm được: upload ra <id>.tar.tmp rồi rename trong cùng share — rename cùng volume là nguyên tử, người đọc không bao giờ thấy file tar dở dang.
6. Phân quyền sẵn: user cục bộ trên DSM + quyền theo share, tách read-only / read-write.

Bố cục share đề xuất trên NAS2

\\172.16.20.201\lotus_profiles\
├── profiles/<profile_id>.tar          ← kho chính (không nén)
├── incoming/<profile_id>.<host>.tmp   ← vùng ghi tạm, rename sang profiles/ khi xong
├── quarantine/<profile_id>.<ts>.tar   ← bản lỗi/hỏng, giữ để điều tra
└── _index/manifest.json               ← sổ cái (size, sha256, status, audit) cho FileStation API đọc nhanh

✅ Kiểm chứng cơ chế — chạy thật end-to-end 2026-08-05

Công cụ tham chiếu docs/tools/profile_store.py đã chạy full vòng đời trực tiếp trên NAS2 — share \\172.16.20.201\lotus_profiles (SMB3, /volume1) — với profile GPM Chrome thật lấy từ …/03_Trans/03_GPM_Profile/.

Còn hở gì khi lên production (đánh giá thẳng thắn)

Lệnh đã chạy để kiểm chứng nằm trong docs/tools/profile_store.py (mục docstring có ví dụ đầy đủ). Chi tiết văn bản: docs/great-lotus-e2e-architecture.md §7.5.

✅ Phân quyền · Khoá phiên · Nối vào worker 2026-08-05

(a) Phân quyền share — verify bằng mount thật

Worker mount bằng RW; n8n/kiểm kê (container Linux) dùng RO. Credential ở tầng OS (net use … /user:WP2_GPM_Profile_RW / credentials= file), không nhúng code.

(b) Khoá phiên (lease) — test trực tiếp trên NAS2 qua VPN

(c) Nối vào worker — profile_nas_sync.py + 2 hook, mặc định TẮT

_run_profile_action gọi nas_sync_before_open (giành lease + pull --lease) trước khi mở, và nas_sync_after_close (push + nhả lease) sau khi đóng. Import có guard + nuốt mọi lỗi ⇒ NAS treo/mount rớt không bao giờ làm hỏng thao tác browser.

(d) Sự cố: workflow lỗi / worker crash ⇒ lease có kẹt vĩnh viễn không? KHÔNG

Lease luôn có TTL (env LOTUS_PROFILE_LEASE_TTL), và trong khi profile MỞ worker tự động gia hạn (heartbeat) mỗi TTL/3 giây. Đã test trên NAS2 (TTL 15s, renew 10s):

🚀 Cách BẬT sync trên máy worker (3 bước)

Mặc định TẮT — worker chạy y như trước. Bật khi đã sẵn sàng, chỉ trên máy worker (Windows). Cấu hình đặt ngay trong file .bat khởi động (dùng setlocal nên python và các lệnh profile_store.py con tự kế thừa): App\2_GPM_Multi_Remote_Browser_Process_Manager_GUI\2_GPM_multi_remote_browser_process_manager_gui.bat

Bước 1 — Lưu credential một lần (KHÔNG gõ mật khẩu vào file). Chạy trong CMD trên worker:

cmdkey /add:172.16.20.201 /user:WP2_GPM_Profile_RW /pass
rem  (Windows hỏi mật khẩu → gõ pass của WP2_GPM_Profile_RW. Từ đó truy cập \\172.16.20.201\... không cần đăng nhập lại)

Bước 2 — Điền thư mục GPM (dòng đã có sẵn trong .bat). Tìm đường dẫn trong app GPM Login → Cài đặt → Đường dẫn lưu trữ (nơi có các folder <id> hoặc <id>-<ngày>):

set "LOTUS_GPM_PROFILE_DIR=C:\...\GPM_Profiles"   <-- ĐIỀN đúng thư mục này
set "LOTUS_GPM_PROFILE_GLOB={id}"                <-- đổi thành {id}-*  nếu tên folder có hậu tố ngày

Bước 3 — Bật cờ rồi chạy lại .bat:

set "LOTUS_PROFILE_NAS_SYNC=1"

Bảng biến môi trường

📊 B36 — Trang quản lý profile (Profile Fleet Dashboard) 2026-08-06

Container lotus_profile_dashboard (IP 114.114.114.36) — một dashboard CHỈ ĐỌC giống ScanIpProxy, đọc thẳng kho lotus_profiles trên NAS2 và hiển thị theo WP1 / WP2 / WP3: số lượng, dung lượng, profile đang chạy ở máy nào, profile lỗi + lý do, số lần chạy, thời lượng, chạy gần nhất, hạn mức cache.

# build + chạy (trên HP1)
cd .../DCP_PRODUCTION
docker compose up -d --build lotus_profile_dashboard
# đổi code Python -> restart để uvicorn nạp lại; static bind-mount nên sửa là thấy ngay
docker compose restart lotus_profile_dashboard

Nguồn IP đến từ đâu

DCOM USB-4G (ZTE/OLAX)  ──USB──►  DELL_Proxy 172.16.20.202  ──admin :6868──►  RapidProxyClient
   (nhà mạng cấp IP mobile)         (trang trại proxy HTTP/Socks5)              (Docker trên Pi1
                                     nội bộ 10.10.10.x / 10.10.11.x)             172.16.20.203)
                                                                                       │ MQTT
                                                                                       ▼
                                                                    RapidProxyHost  ──► Redis B27
                                                                                       │
                                              ScanIpProxy (B30, quét mỗi 1s) ◄─────────┘
                                                 └─ MQTT topic SEND_TO_RAPID_PROXY_MAN
                                                    ({type: changeIpRequest | rebootDcomRequest})

Redis key — namespace LOTUS:

Đã liệt kê trực tiếp trên container lotus_redis (B27, host 20270).

Hình dạng một phần tử trong 03/04/05

{ "workpool": "WP2",
  "dcomEntry": { "id":"eth1", "name":"eth1", "isp":"VIETNAMMOBILE",
                 "publicIPv4Address":"103.249.23.109", "localIPv4Address":"192.168.164.100",
                 "httpPort":2001, "socks5Port":4001, "proxyStatus":"Running", … },
  "enteredNewAt": 1785868525.12 }   // hoặc enteredUsingAt / enteredDoneAt

Mật khẩu Redis nằm ở REDIS_ARGS --requirepass trong docker-compose.yml — đừng chép ra tài liệu/chat.

Vòng đời IP — state machine

1. 03_NEW_IP — ScanIpProxy thấy DCOM có publicIPv4Address mới & hợp lệ → RPUSH.
2. 04_USING_IP — (n8n/worker phải tự làm) lấy IP ra, đặt enteredUsingAt.
3. Timeout — nằm ở USING quá USING_TIMEOUT_SEC (3600s): ScanIpProxy ghi audit ip_timeout, đẩy sang 05_DONE_IP, publish rebootDcomRequest, POST webhook cảnh báo về n8n → Webex.
4. 05_DONE_IP — xong việc. ScanIpProxy publish changeIpRequest để Client xoay IP rồi xoá khỏi hàng đợi. IP mới xuất hiện lại ở 03_NEW_IP.
5. Mất IP > 60s (RESET_TIMEOUT_SEC) — publish rebootDcomRequest (reset cổng USB) — self-healing.

Ngoài Redis còn 2 SQLite trong WebDashboard/data/: audit.db (sự kiện 90 ngày, xếp hạng DCOM hay reboot → tìm cổng USB hỏng) và ip_stats.db (tỉ lệ IP trùng, kích thước pool thật của nhà mạng).

API HTTP để n8n dùng thay vì nói chuyện Redis trực tiếp

Base: http://172.16.10.220:20300 hoặc https://scanipproxy.lotus1104.synology.me/

🔴 HAI VẤN ĐỀ PHẢI XỬ LÝ TRƯỚC KHI DÙNG THẬT

Trạng thái đo được lúc khảo sát 2026-08-05 ~01:40

• 01_INFO: WP2 / DELL_PROXY_01 / DCOM eth1 (ZTE, VIETNAMMOBILE, LTE, signal 5, proxyStatus: Running) nhưng publicIPv4Address đang là chuỗi rỗng, lastReset cập nhật liên tục ⇒ DCOM đang xoay IP / chưa bắt được mạng.
• ⇒ 03_NEW_IP, 04_USING_IP, 05_DONE_IP đều rỗng. Redis xoá key khi list rỗng — key không xuất hiện trong KEYS * là bình thường, không phải mất dữ liệu.
• 02_ALIVE: Pi1 (WP2_Rasp_Pi3_b827eb729e41) aliveStatus: true ⇒ đường Client → Host → Redis đang sống.

Trang quản trị DCOM 172.16.20.202:6868 — truy cập được từ mạng khác không?

Quy trình hoàn chỉnh — truy xuất & chạy một Chrome profile

Bản mô tả gốc có 6 bước và ghi "có thể chưa hoàn thiện". Dưới đây là bản đã bổ sung các bước thiếu.

 n8n workflow                Worker (NUC1)                  Hạ tầng
 ─────────────               ──────────────                 ──────────
 (0) lease profile ─────────────────────────────────────► Redis B27  SET NX EX   [THIẾU]
 (1) claim IP ──────────────────────────────────────────► Redis 03_NEW → 04_USING [THIẾU]
 (2) kiểm tra sức khoẻ proxy ───────────────────────────► CONNECT thử qua proxy   [THIẾU]
 (3) tải + xả .tar ─── MQTT ──► worker ─── SMB ─────────► NAS2 \\…\profiles\<id>.tar [ĐÃ NỐI (C12): node pull_profile → profile_store.py pull]
 (4) update_profile(raw_proxy) ─ MQTT ──► GPM API                                  [CÓ]
 (5) open_profile ────────────── MQTT ──► GPM API ──► Chrome + cổng CDP            [CÓ]
 (6) xác minh IP ra ngoài ───── MQTT ──► browser.url ip-echo → so IP đã claim      [THIẾU]
 (7) chạy nghiệp vụ ─────────── MQTT ──► C10 Playwright / C12 PyAutoGUI            [CÓ]
 (8) quit(remote_port) ──────── MQTT ──► đóng đúng 1 session                       [CÓ]
 (9) close_profile ──────────── MQTT ──► GPM flush profile ra đĩa                  [CÓ]
(10) đóng .tar + upload nguyên tử ── SMB ──► NAS2 incoming/ → rename → profiles/   [ĐÃ NỐI (C12): node push_profile → profile_store.py push]
(11) release IP 04 → 05 ───────────────────────────────► Redis                     [THIẾU]
(12) release lease + xoá thư mục tạm local                                         [THIẾU]

Diễn giải từng bước

0. Giành quyền dùng profile (lease) THIẾU n8n
   Một profile Chrome không được mở đồng thời trên 2 máy — Chrome khoá --user-data-dir bằng SingletonLock, và tệ hơn là 2 máy cùng upload .tar sẽ ghi đè lẫn nhau ⇒ mất cookie. Dùng Redis B27 (đã có sẵn, đừng dựng hạ tầng mới): SET LOTUS:04_PROFILE:LEASE:<profile_id> "<wp>/<pc>/<run_id>" NX EX 5400. Không lấy được ⇒ chọn profile khác hoặc dừng. TTL bắt buộc để worker chết không khoá vĩnh viễn.
1. Giành IP THIẾU n8n
   Đọc 03_NEW_IP, chọn 1 phần tử, chuyển sang 04_USING_IP. Từ dcomEntry dựng <proxyDevIp>:<httpPort> (HTTP) hoặc :<socks5Port> (Socks5), kèm user/pass nếu cần → định dạng GPM host:port:user:pass. ⚠ Trước khi làm phải tắt AUTO_MOVE và dùng đường nguyên tử (xem tab IP Pool).
2. Kiểm tra sức khoẻ proxy TRƯỚC khi mở browser THIẾU worker
   Bài học từ chính lần khảo sát này: DCOM báo proxyStatus: "Running" nhưng publicIPv4Address rỗng. Mở browser với proxy chết = mất 30–60s timeout rồi hỏng cả run. Kiểm tra rẻ tiền: TCP connect tới host:port + 1 request qua proxy tới trang echo IP. Hỏng ⇒ trả IP về 05_DONE_IP (kích hoạt xoay IP) rồi claim IP khác.
3. Tải profile từ NAS ĐÃ NỐI (C12) worker
   ✅ 2026-08-09: node manager.pull_profile (nhóm Manager, trên cùng) → worker chạy profile_store.py pull (giành lease + heartbeat), xả nén ra LOTUS_GPM_PROFILE_DIR\<id>\, đọc config.json lấy current_cache_limit_mb. Profile chưa tồn tại trên NAS ⇒ nhánh "tạo mới": manager.create_profile rồi coi như profile trắng. C10 sẽ nhân bản node này sau. Điều kiện worker: có profile_store.py + đã mount kho NAS2 (RW).
4. Gắn proxy vào profile CÓ worker
   manager.update_profile(profile_id, raw_proxy=…). 🔴 Bắt buộc là bước riêng. open_profile (= GET /profiles/start/<id>) chỉ nhận addination_args/remote_port/win_* — không có tham số proxy. Profile vẫn chạy được với proxy, nhưng là proxy đã lưu sẵn trên nó (đặt bằng create_profile/update_profile). Muốn đổi proxy MỚI (lấy IP từ pool) ⇒ update_profile TRƯỚC rồi mới open.
5. Mở profile CÓ worker
   manager.open_profile(profile_id, addination_args=…). ✅ AUTO-ARGS (C12, 2026-08-09): bật load_args_from_config (mặc định) ⇒ worker tự đọc config.json (do bước 3 tải về) rồi nhét --disk-cache-size=<current_cache_limit_mb×1MB>, --media-cache-size=1, --disable-pdf-viewer + additional_args vào addination_args (không đè cờ gõ tay). Node C10 rút cổng CDP từ response và gắn vào output remote_debugging_port + remote_port ⇒ mọi node sau tự nối đúng session.
6. Xác minh IP ra ngoài THIẾU worker
   Proxy có thể bị bỏ qua âm thầm (profile GPM còn giữ proxy cũ, hoặc Chrome bỏ qua cờ khi đã có instance cùng user-data-dir). Điều hướng tới một trang echo IP và so với IP đã claim. Lệch ⇒ hủy run ngay — đừng chạy nghiệp vụ với IP sai, đó chính là thứ làm cháy tài khoản.
7. Chạy nghiệp vụ CÓ n8n worker
   Chuỗi node C10/C12. Nhớ: C12 bị mutex tuần tự hoá (chuột/bàn phím vật lý là tài nguyên độc quyền của OS), C10 chạy song song được.
8. Đóng session CÓ worker
   manager.quit với quit_all = false + đúng remote_port. 🔴 Bật Quit All sẽ giết luôn browser của các nhánh song song.
9. Đóng profile GPM CÓ worker
   manager.close_profile(profile_id) — để GPM/Chrome flush hết cookie/SQLite ra đĩa. Đóng gói khi Chrome còn sống sẽ ra bản .tar thiếu dữ liệu (nằm trong -wal). Mẹo đã kiểm chứng ở A13: nếu buộc phải chụp khi Chrome còn chạy, dùng SQLite backup API cho mọi file có header SQLite format 3 rồi xoá -wal/-shm — đo được 501 cookie so với 500 khi chỉ copy thô.
10. Đóng gói + upload nguyên tử ĐÃ NỐI (C12) worker
    ✅ 2026-08-09: node manager.push_profile (nhóm Manager, trên cùng) → worker chạy profile_store.py push: đo cache thật → tính AIMD → ghi config.json → tar không nén → ghi ra incoming/<id>.<host>.tmp → rename sang profiles/<id>.tar (nguyên tử cùng share) → nhả lease. Chạy sau close_profile. C10 sẽ nhân bản node này sau.
11. Trả IP THIẾU n8n
    04_USING_IP → 05_DONE_IP. ScanIpProxy sẽ tự phát changeIpRequest và xoá khỏi hàng đợi.
12. Dọn dẹp THIẾU n8n worker
    DEL lease key; rmtree C:\temp_profiles\<id>. Không dọn = ổ SSD đầy sau vài trăm run.

Đường thất bại (compensation) — bắt buộc thiết kế

Ai nên làm bước nào — n8n hay worker?

Khoảng trống giữa "mô tả" và "code thật"

Cạm bẫy đã trả giá — đừng vấp lại

Lệnh kiểm chứng nhanh chạy trên HP1

Container & mạng

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
ping -c1 172.16.30.101      # NUC1 (WP3)
ping -c1 172.16.20.201      # NAS2 (WP2)

Fleet Monitor — máy nào đang online?

curl -s http://127.0.0.1:20340/api/state | python3 -m json.tool | head -40

IP Pool qua HTTP (không cần mật khẩu Redis)

curl -s http://127.0.0.1:20300/api/redis/all
curl -s http://127.0.0.1:20300/api/redis/new-ip
curl -s http://127.0.0.1:20300/api/redis/config/auto-move

Redis trực tiếp — mật khẩu lấy từ compose, KHÔNG gõ inline

COMPOSE=Application/APP_1_GREAT_LOTUS_PROJECT/App/A0_DCP_GREATE_LOTUS_NETWORK/DCP_PRODUCTION/docker-compose.yml
export REDISCLI_AUTH=$(grep -m1 -oP '(?<=--requirepass )\S+' "$COMPOSE")
docker exec -e REDISCLI_AUTH lotus_redis redis-cli --no-auth-warning KEYS 'LOTUS:03_PROXY:*'

n8n API — key lấy từ .env

KEY=$(grep -m1 '^N8N_API_KEY=' …/DCP_PRODUCTION/.env | cut -d= -f2-)
curl -s -H "X-N8N-API-KEY: $KEY" http://127.0.0.1:20150/api/v1/workflows?limit=100

NAS2 — cổng nào mở?

for p in 22 139 445 873 5000 5001 5005 6690; do
  timeout 3 bash -c "echo > /dev/tcp/172.16.20.201/$p" 2>/dev/null \
    && echo "$p OPEN" || echo "$p closed"; done

Danh mục file quan trọng

Quy ước khi cập nhật tài liệu

Thứ tự ưu tiên nguồn sự thật: thiết bị/API thật > mã nguồn > file cấu hình trong git > sơ đồ/báo cáo HTML.

File config trong repo có thể lệch với máy worker thật (đã gặp: pc_name). Trang HTML này và bản Markdown docs/great-lotus-e2e-architecture.md phải được cập nhật cùng nhau.