บนแล็ปท็อป OpenClaw เงียบทันทีที่ปิดฝาจอ ข้อความ WhatsApp กองสุม งานที่ตั้งเวลาไว้ก็รอจนกว่าคุณจะกลับมา บนเซิร์ฟเวอร์มันจะตอบต่อไปเรื่อย ๆ ปัญหาคือเกตเวย์ไม่ใช่วิดเจ็ตแชต มันเก็บข้อมูลรับรองของทุกช่องทาง และถ้าคุณไม่เปิดแซนด์บ็อกซ์ มันจะรันเครื่องมือบนโฮสต์โดยตรง การย้ายมันไปไว้บนเครื่องที่เปิดตลอดเวลาจะคุ้มก็ต่อเมื่อย้ายโมเดลความปลอดภัยไปด้วย
คู่มือนี้ทำเรื่องนั้นภายในราว 20 นาทีบน VPS Ubuntu 24.04 ที่เพิ่งสร้าง
ตรวจสอบล่าสุด 2026-10-04 กับ OpenClaw 2026.9.8 (npm), Node 24.21 LTS และ Ubuntu 24.04
สิ่งที่ต้องมี
- Linux VPS หนึ่งเครื่อง เราใช้ แพ็กเกจ AI-Agent ของเรา: 4 vCPU, RAM 4 GB, ดิสก์ 40 GB, เดือนละ $10 เอกสาร OpenClaw พูดถึง RAM 6 GB แต่นั่นสำหรับ build อิมเมจ Docker ของพวกเขาจากซอร์สโค้ด แพ็กเกจ npm ไม่ต้อง build
- API key จากผู้ให้บริการโมเดล และบัญชีแชตที่ต้องการเชื่อม
- SSH key บนแล็ปท็อป ถ้ายังไม่มี: ล็อกอินด้วย SSH key
แพ็กเกจ NAT ใช้ได้ดีในกรณีนี้ และอาจเหมาะกว่าด้วย เกตเวย์ไม่จำเป็นต้องมีพอร์ตขาเข้าที่เปิดไว้เลย WhatsApp, Discord และ Telegram (ค่าเริ่มต้นเป็น long polling) เชื่อมต่อออกไปเอง ส่วนแดชบอร์ดคุณเข้าผ่าน SSH เลือก IPv4 เฉพาะก็ต่อเมื่อมีช่องทางที่จำเป็นต้องส่งข้อความผ่าน webhook หรือคุณวางแผนจะใช้ reverse proxy สาธารณะ
1. ผู้ใช้ที่ไม่ใช่ root
OpenClaw รันเครื่องมือในนามผู้ใช้ที่เป็นเจ้าของเกตเวย์ ถ้าผู้ใช้นั้นคือ root ทุกคำสั่งที่โมเดลซึ่งสับสนหรือถูก prompt injection ชักนำตัดสินใจรัน ก็จะรันเป็น root ด้วย เอกสาร OpenClaw ระบุว่าการรันเกตเวย์เป็น root ไม่ปลอดภัยและไม่ได้รับการสนับสนุน สร้างผู้ใช้เฉพาะที่ไม่มี sudo:
# ในฐานะ root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys # คีย์ที่คุณเพิ่มตอนสั่งซื้อ
loginctl enable-linger claw
บรรทัดสุดท้ายสำคัญกว่าที่เห็น OpenClaw ติดตั้งบริการ systemd ระดับ ผู้ใช้ และถ้าไม่มี lingering บริการนั้นจะหยุดเมื่อคุณล็อกเอาต์ นี่คือ "เมื่อวานยังใช้ได้อยู่เลย" ที่พบบ่อยที่สุดบนเซิร์ฟเวอร์
2. Node 24 และ OpenClaw
OpenClaw 2026.9.8 ต้องการ Node >=24.16.0 <25 หรือ >=26.1.0 แพ็กเกจ nodejs ของ Ubuntu เก่ากว่านั้น เราจึงใช้ 24 LTS จาก NodeSource:
# ในฐานะ root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v # v24.16.0 ขึ้นไป
npm install -g openclaw@latest
openclaw --version
คำสั่งบรรทัดเดียวอย่างเป็นทางการ (curl -fsSL https://openclaw.ai/install.sh | bash) ก็ใช้ได้และติดตั้ง Node ให้ด้วย บนเซิร์ฟเวอร์เราชอบสองขั้นตอนแบบชัดเจนมากกว่า เพราะเห็นว่าอะไรไปอยู่ที่ไหน และไฟล์รันอยู่ใน /usr/bin แทนที่จะอยู่ในโฮมไดเรกทอรีที่เอเจนต์เขียนได้
3. Onboarding ในฐานะผู้ใช้ของเอเจนต์
ล็อกอิน เป็น claw ผ่าน SSH ไม่ใช่ด้วย su การล็อกอินจริงเท่านั้นที่จะเริ่มตัวจัดการผู้ใช้ของ systemd ที่บริการต้องใช้:
# จากแล็ปท็อป (แพ็กเกจ NAT: เพิ่ม -p <พอร์ต SSH ของคุณ>)
ssh claw@<server>
openclaw onboard --install-daemon
openclaw gateway status
ตัวช่วยตั้งค่าจะตรวจการเข้าถึงโมเดล เขียน ~/.openclaw/openclaw.json สร้างโทเค็นเกตเวย์ และติดตั้งบริการ ถ้า systemctl --user บ่นเรื่อง bus ให้ตั้ง export XDG_RUNTIME_DIR=/run/user/$(id -u) แล้วลองใหม่
จากนั้นล็อกไฟล์ให้แน่น คำแนะนำของ OpenClaw เองคือ 700 สำหรับไดเรกทอรีสถานะ และ 600 สำหรับไฟล์คอนฟิก:
chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep
openclaw security audit --fix ใช้เฉพาะส่วนการแก้ไขที่ปลอดภัย: สิทธิ์ไฟล์ที่เข้มงวดขึ้น และ allowlist แทนนโยบายกลุ่มแบบเปิด มันไม่เปลี่ยนที่อยู่ที่ฟัง และไม่ตั้งไฟร์วอลล์ให้ การเปิดเผยต่อเครือข่ายยังเป็นหน้าที่ของคุณ
4. ให้เกตเวย์อยู่ที่ loopback
เกตเวย์ให้บริการ WebSocket API และแดชบอร์ดบนพอร์ตเดียวคือ 18789 ซึ่งผูกกับ 127.0.0.1 เป็นค่าเริ่มต้น ปล่อยไว้อย่างนั้น คอนฟิกขั้นต่ำที่เขียนเรื่องนี้ไว้ชัดเจน:
// ~/.openclaw/openclaw.json
{
gateway: {
mode: "local",
bind: "loopback",
port: 18789,
auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
},
}
สร้างโทเค็นด้วย openssl rand -hex 32 หรือ openclaw doctor --generate-gateway-token เกตเวย์ปฏิเสธโทเค็นว่างและค่าตัวอย่าง และการตรวจสอบจะเตือนถ้าสั้นกว่า 24 ตัวอักษร
สิ่งที่ไม่ควรทำ: ตั้ง bind เป็น "lan" แล้วเปิดพอร์ต เอกสารพูดตรง ๆ ว่าอย่าเปิดเกตเวย์โดยไม่มีการยืนยันตัวตนบน 0.0.0.0 และอย่าส่งต่อพอร์ตแบบกว้าง ๆ แม้จะมีโทเค็น ใครได้โทเค็นนั้นไปก็จะกลายเป็นผู้ควบคุมโปรเซสที่รันคำสั่งบนเซิร์ฟเวอร์ของคุณได้
ฝั่งไฟร์วอลล์ อนุญาตแค่ SSH ไม่มีอย่างอื่น:
# ในฐานะ root
ufw allow OpenSSH
ufw enable
ufw status verbose
บนแพ็กเกจ NAT ของเรา แดชบอร์ดแสดงพอร์ต SSH ภายนอก แต่ภายในเซิร์ฟเวอร์ sshd ยังฟังที่ 22 ให้อนุญาต OpenSSH (พอร์ต 22) ไม่ใช่ หมายเลขพอร์ตภายนอก ไม่อย่างนั้น ufw enable จะล็อกคุณไว้ข้างนอก อ่านเพิ่มใน คู่มือ UFW
5. เข้าแดชบอร์ดผ่าน SSH
จากแล็ปท็อป เปิดอุโมงค์และปล่อยให้ทำงานไว้:
ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# แพ็กเกจ NAT: ssh -N -p <พอร์ต SSH ของคุณ> -L 18789:127.0.0.1:18789 claw@<host>
เปิด http://127.0.0.1:18789/ แล้ววางโทเค็นเกตเวย์ sshd ค่าเริ่มต้นของ Ubuntu อนุญาต local forwarding ถ้าคุณเคยปรับให้เข้มงวด AllowTcpForwarding local คือค่าที่อนุญาต -L แต่บล็อก remote forward ถ้าอุโมงค์ล้มเหลวด้วย administratively prohibited ให้ตรวจบรรทัดนี้
ใช้ tailnet ก็ได้: Tailscale Serve คงเกตเวย์ไว้ที่ loopback และจัดการการเข้าถึงให้ ทั้งสองแบบใช้ได้ พอร์ตสาธารณะใช้ไม่ได้
6. การจับคู่ แซนด์บ็อกซ์ และใครคุยกับมันได้
ช่องทางแชตคือประตูอีกบาน โดยค่าเริ่มต้น ช่องทางที่รับข้อความส่วนตัวจะให้ผู้ส่งที่ไม่รู้จักจับคู่ก่อน คุณเป็นคนอนุมัติจากเซิร์ฟเวอร์:
openclaw pairing approve <channel> <code>
ในกลุ่ม ให้บังคับการเมนชัน เพื่อไม่ให้เอเจนต์ตอบทุกข้อความในห้อง คอนฟิกพื้นฐานแบบเสริมความปลอดภัยของ OpenClaw ใช้ dmPolicy: "pairing" และ groups: { "*": { requireMention: true } } ต่อช่องทาง
ข้อควรระวังตามตรงสองข้อ ข้อแรก: การจับคู่กำหนดว่าใคร เริ่ม รอบการทำงานได้ ไม่ได้กำหนดว่าอะไรจะเข้าไปอยู่ในบริบทของโมเดล ข้อความที่ส่งต่อมาหรือหน้าเว็บที่ดึงมายังชี้นำรอบที่คุณเริ่มเองได้ ข้อสอง: เครื่องมือของเซสชันหลักรันบนโฮสต์จนกว่าคุณจะเปิดแซนด์บ็อกซ์ (agents.defaults.sandbox.mode: "non-main" แยกทุกอย่างยกเว้นเซสชันหลักของคุณเอง) แซนด์บ็อกซ์ปิดเป็นค่าเริ่มต้น และแบ็กเอนด์เริ่มต้นคือ Docker จึงควรติดตั้ง Docker ก่อนเปิด: Docker บน VPS ถ้าคนที่คุณไม่ไว้ใจใช้ช่องทางเดียวกับบอต ให้ใช้เกตเวย์แยก ดีที่สุดคือบนเซิร์ฟเวอร์แยก
7. การอัปเดตและสำรองข้อมูล
openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify
~/.openclaw เก็บคอนฟิก ข้อมูลรับรองของช่องทาง (รวมเซสชัน WhatsApp) โปรไฟล์การยืนยันตัวตนของโมเดล และบันทึกเซสชัน ถ้าหายต้องจับคู่ใหม่ทั้งหมด ถ้ารั่วคนอื่นจะกลายเป็นคุณบน WhatsApp สำรองไว้และเก็บสำเนานอกเซิร์ฟเวอร์ ดาวน์โหลดด้วย scp หรือใช้ restic แบบเข้ารหัส
รายการตรวจสอบ
| ตรวจสอบ | คำสั่ง | ผลที่คาดหวัง |
|---|---|---|
| เกตเวย์ไม่ได้รันเป็น root | ps -eo user,args | grep '[o]penclaw' | คอลัมน์แรกเป็น claw |
| ยังทำงานหลังล็อกเอาต์ | loginctl show-user claw -p Linger | Linger=yes |
| ฟังเฉพาะ loopback | ss -ltnp | grep 18789 | 127.0.0.1:18789 |
| ไม่มีพอร์ตสาธารณะ | ufw status | มีแค่ OpenSSH |
| คอนฟิกไม่ให้ทุกคนอ่านได้ | stat -c '%a' ~/.openclaw/openclaw.json | 600 |
| ผลตรวจสอบสะอาด | openclaw security audit --deep | ไม่มีปัญหาร้ายแรง |
EQVPS อยู่ตรงไหน
ผู้ให้บริการหลายรายรันโปรเซส Node ได้ สิ่งที่เราเพิ่มคือการชำระด้วยคริปโตโดยไม่ต้อง KYC แพ็กเกจ NAT ที่เหมาะกับเกตเวย์ที่ฟังเฉพาะ loopback และ เซิร์ฟเวอร์ MCP ที่เอเจนต์ของคุณใช้จัดการเซิร์ฟเวอร์ของตัวเองได้ ถ้าคุณเชื่อม OpenClaw เข้ากับมัน ให้อ่าน รั้วกั้นความปลอดภัย MCP ก่อน โทเค็นที่สั่งซื้อเซิร์ฟเวอร์ได้ควรได้รับความระมัดระวังเท่ากับโทเค็นเกตเวย์ สำหรับภาพกว้างเรื่องการรันเอเจนต์บน VPS ดู คู่มือเอเจนต์ AI
ความเห็นของเรา: 20 นาทีนี้คือความต่างระหว่างผู้ช่วยกับ shell ที่เปิดโล่งพร้อมหน้าจอแชต ต่อให้ข้ามขั้นอื่น อย่างน้อยให้ทำขั้นที่ 1, 4 และ 5
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ