---
read_when:
    - การเรียกใช้โฮสต์ Node แบบไม่มีส่วนติดต่อผู้ใช้
    - การจับคู่ Node ที่ไม่ใช่ macOS สำหรับ system.run
summary: ข้อมูลอ้างอิง CLI สำหรับ `openclaw node` (โฮสต์ Node แบบไร้ส่วนติดต่อผู้ใช้)
title: Node
x-i18n:
    generated_at: "2026-05-06T17:54:25Z"
    model: gpt-5.5
    provider: openai
    source_hash: af4735ac4961dc36fd3f11299eb3ec4e156835e7257b21a79bb1d4b467445faa
    source_path: cli/node.md
    workflow: 16
---

# `openclaw node`

เรียกใช้**โฮสต์โหนดแบบไม่มีส่วนติดต่อผู้ใช้**ที่เชื่อมต่อกับ Gateway WebSocket และเปิดให้ใช้
`system.run` / `system.which` บนเครื่องนี้

## ทำไมต้องใช้โฮสต์โหนด?

ใช้โฮสต์โหนดเมื่อคุณต้องการให้เอเจนต์**เรียกใช้คำสั่งบนเครื่องอื่น**ในเครือข่ายของคุณ
โดยไม่ต้องติดตั้งแอปคู่หู macOS แบบเต็มไว้ที่นั่น

กรณีใช้งานทั่วไป:

- เรียกใช้คำสั่งบนเครื่อง Linux/Windows ระยะไกล (เซิร์ฟเวอร์บิลด์, เครื่องแล็บ, NAS)
- ทำให้ exec ยังคงอยู่ใน**แซนด์บ็อกซ์**บน Gateway แต่ส่งต่อการรันที่ได้รับอนุมัติไปยังโฮสต์อื่น
- จัดหาเป้าหมายการประมวลผลแบบเบาและไม่มีส่วนติดต่อผู้ใช้สำหรับโหนดระบบอัตโนมัติหรือ CI

การประมวลผลยังคงถูกควบคุมด้วย**การอนุมัติ exec**และ allowlist รายเอเจนต์บน
โฮสต์โหนด ดังนั้นคุณจึงสามารถจำกัดขอบเขตและกำหนดสิทธิ์การเข้าถึงคำสั่งได้อย่างชัดเจน

## พร็อกซีเบราว์เซอร์ (ไม่ต้องตั้งค่า)

โฮสต์โหนดจะประกาศพร็อกซีเบราว์เซอร์โดยอัตโนมัติ หากไม่ได้ปิดใช้ `browser.enabled`
บนโหนด ซึ่งทำให้เอเจนต์ใช้ระบบอัตโนมัติของเบราว์เซอร์บนโหนดนั้นได้
โดยไม่ต้องตั้งค่าเพิ่มเติม

โดยค่าเริ่มต้น พร็อกซีจะเปิดเผยพื้นผิวโปรไฟล์เบราว์เซอร์ปกติของโหนด หากคุณ
ตั้งค่า `nodeHost.browserProxy.allowProfiles` พร็อกซีจะกลายเป็นแบบจำกัด:
การกำหนดเป้าหมายโปรไฟล์ที่ไม่ได้อยู่ใน allowlist จะถูกปฏิเสธ และเส้นทาง
สร้าง/ลบโปรไฟล์แบบถาวรจะถูกบล็อกผ่านพร็อกซี

ปิดใช้บนโหนดได้หากจำเป็น:

```json5
{
  nodeHost: {
    browserProxy: {
      enabled: false,
    },
  },
}
```

## เรียกใช้ (เบื้องหน้า)

```bash
openclaw node run --host <gateway-host> --port 18789
```

ตัวเลือก:

- `--host <host>`: โฮสต์ Gateway WebSocket (ค่าเริ่มต้น: `127.0.0.1`)
- `--port <port>`: พอร์ต Gateway WebSocket (ค่าเริ่มต้น: `18789`)
- `--tls`: ใช้ TLS สำหรับการเชื่อมต่อ Gateway
- `--tls-fingerprint <sha256>`: ลายนิ้วมือใบรับรอง TLS ที่คาดไว้ (sha256)
- `--node-id <id>`: แทนที่รหัสโหนด (ล้างโทเค็นการจับคู่)
- `--display-name <name>`: แทนที่ชื่อที่แสดงของโหนด

## การยืนยันตัวตน Gateway สำหรับโฮสต์โหนด

`openclaw node run` และ `openclaw node install` แก้ค่าการยืนยันตัวตน Gateway จาก config/env (ไม่มีแฟล็ก `--token`/`--password` บนคำสั่งโหนด):

- ตรวจสอบ `OPENCLAW_GATEWAY_TOKEN` / `OPENCLAW_GATEWAY_PASSWORD` ก่อน
- จากนั้นใช้ค่าท้องถิ่นสำรอง: `gateway.auth.token` / `gateway.auth.password`
- ในโหมดท้องถิ่น โฮสต์โหนดจงใจไม่สืบทอด `gateway.remote.token` / `gateway.remote.password`
- หากกำหนดค่า `gateway.auth.token` / `gateway.auth.password` อย่างชัดเจนผ่าน SecretRef และแก้ค่าไม่ได้ การแก้ค่าการยืนยันตัวตนของโหนดจะปิดโดยปริยาย (ไม่มี remote fallback มาปิดบัง)
- ใน `gateway.mode=remote` ฟิลด์ไคลเอนต์ระยะไกล (`gateway.remote.token` / `gateway.remote.password`) จะมีสิทธิ์ใช้งานได้ด้วยตามกฎลำดับความสำคัญของระยะไกล
- การแก้ค่าการยืนยันตัวตนของโฮสต์โหนดจะเคารพเฉพาะตัวแปร env `OPENCLAW_GATEWAY_*`

สำหรับโหนดที่เชื่อมต่อกับ Gateway `ws://` ที่ไม่ใช่ local loopback บนเครือข่ายส่วนตัว
ที่เชื่อถือได้ ให้ตั้งค่า `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` หากไม่มีค่านี้ การเริ่มต้นโหนด
จะปิดโดยปริยายและขอให้คุณใช้ `wss://`, ทันเนล SSH หรือ Tailscale
นี่เป็นการเลือกเข้าร่วมผ่านสภาพแวดล้อมของกระบวนการ ไม่ใช่คีย์ config `openclaw.json`
`openclaw node install` จะบันทึกค่านี้ไว้ในบริการโหนดที่ถูกควบคุมเมื่อค่าอยู่ใน
สภาพแวดล้อมของคำสั่งติดตั้ง

## บริการ (เบื้องหลัง)

ติดตั้งโฮสต์โหนดแบบไม่มีส่วนติดต่อผู้ใช้เป็นบริการผู้ใช้

```bash
openclaw node install --host <gateway-host> --port 18789
```

ตัวเลือก:

- `--host <host>`: โฮสต์ Gateway WebSocket (ค่าเริ่มต้น: `127.0.0.1`)
- `--port <port>`: พอร์ต Gateway WebSocket (ค่าเริ่มต้น: `18789`)
- `--tls`: ใช้ TLS สำหรับการเชื่อมต่อ Gateway
- `--tls-fingerprint <sha256>`: ลายนิ้วมือใบรับรอง TLS ที่คาดไว้ (sha256)
- `--node-id <id>`: แทนที่รหัสโหนด (ล้างโทเค็นการจับคู่)
- `--display-name <name>`: แทนที่ชื่อที่แสดงของโหนด
- `--runtime <runtime>`: รันไทม์บริการ (`node` หรือ `bun`)
- `--force`: ติดตั้งใหม่/เขียนทับหากติดตั้งไว้แล้ว

จัดการบริการ:

```bash
openclaw node status
openclaw node start
openclaw node stop
openclaw node restart
openclaw node uninstall
```

ใช้ `openclaw node run` สำหรับโฮสต์โหนดเบื้องหน้า (ไม่มีบริการ)

คำสั่งบริการรองรับ `--json` สำหรับเอาต์พุตที่เครื่องอ่านได้

โฮสต์โหนดจะลองเชื่อมต่อใหม่เมื่อ Gateway รีสตาร์ทและเครือข่ายปิดภายในกระบวนการ หาก
Gateway รายงานการหยุดพักการยืนยันตัวตนด้วยโทเค็น/รหัสผ่าน/bootstrap แบบสิ้นสุด โฮสต์โหนด
จะบันทึกรายละเอียดการปิดและออกด้วยสถานะไม่เป็นศูนย์ เพื่อให้ launchd/systemd สามารถรีสตาร์ทด้วย
config และข้อมูลประจำตัวชุดใหม่ได้ การหยุดพักที่ต้องจับคู่จะยังอยู่ในโฟลว์
เบื้องหน้า เพื่อให้คำขอที่รอดำเนินการสามารถได้รับการอนุมัติ

## การจับคู่

การเชื่อมต่อครั้งแรกจะสร้างคำขอจับคู่อุปกรณ์ที่รอดำเนินการ (`role: node`) บน Gateway
อนุมัติผ่าน:

```bash
openclaw devices list
openclaw devices approve <requestId>
```

บนเครือข่ายโหนดที่ควบคุมอย่างเข้มงวด ผู้ควบคุม Gateway สามารถเลือกเข้าร่วมอย่างชัดเจน
เพื่ออนุมัติการจับคู่โหนดครั้งแรกจาก CIDR ที่เชื่อถือได้โดยอัตโนมัติ:

```json5
{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}
```

ค่านี้ถูกปิดใช้โดยค่าเริ่มต้น ใช้กับการจับคู่ `role: node` ใหม่ที่
ไม่มี scope ที่ร้องขอเท่านั้น ไคลเอนต์ผู้ควบคุม/เบราว์เซอร์, Control UI, WebChat และการอัปเกรด role,
scope, metadata หรือ public-key ยังคงต้องอนุมัติด้วยตนเอง

หากโหนดลองจับคู่ใหม่พร้อมรายละเอียดการยืนยันตัวตนที่เปลี่ยนไป (role/scopes/public key)
คำขอที่รอดำเนินการก่อนหน้าจะถูกแทนที่ และมีการสร้าง `requestId` ใหม่
เรียกใช้ `openclaw devices list` อีกครั้งก่อนอนุมัติ

โฮสต์โหนดจัดเก็บรหัสโหนด โทเค็น ชื่อที่แสดง และข้อมูลการเชื่อมต่อ Gateway ไว้ใน
`~/.openclaw/node.json`

## การอนุมัติ exec

`system.run` ถูกควบคุมด้วยการอนุมัติ exec ท้องถิ่น:

- `~/.openclaw/exec-approvals.json`
- [การอนุมัติ exec](/th/tools/exec-approvals)
- `openclaw approvals --node <id|name|ip>` (แก้ไขจาก Gateway)

สำหรับ exec โหนดแบบ async ที่ได้รับอนุมัติ OpenClaw จะเตรียม `systemRunPlan` มาตรฐาน
ก่อนแสดงพรอมต์ การส่งต่อ `system.run` ที่ได้รับอนุมัติภายหลังจะนำแผนที่จัดเก็บไว้นั้น
กลับมาใช้ ดังนั้นการแก้ไขฟิลด์ command/cwd/session หลังจากสร้างคำขออนุมัติแล้ว
จะถูกปฏิเสธแทนที่จะเปลี่ยนสิ่งที่โหนดประมวลผล

## ที่เกี่ยวข้อง

- [ข้อมูลอ้างอิง CLI](/th/cli)
- [โหนด](/th/nodes)