---
read_when:
    - การใช้การอนุมัติการจับคู่ Node โดยไม่มี UI ของ macOS
    - การเพิ่มโฟลว์ CLI สำหรับอนุมัติ Node ระยะไกล
    - การขยายโปรโตคอล Gateway ด้วยการจัดการ Node
summary: 'การอนุมัติความสามารถของ Node: วิธีที่ Node ได้รับสิทธิ์ให้เรียกใช้คำสั่งหลังจากจับคู่อุปกรณ์แล้ว'
title: การจับคู่ Node
x-i18n:
    generated_at: "2026-07-12T16:12:44Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 753b01681fa9be17df853b63210f54374d054a6dde37746a3b5fda69073af71d
    source_path: gateway/pairing.md
    workflow: 16
---

การจับคู่ Node มีสองชั้น โดยทั้งสองชั้นจัดเก็บอยู่ในระเบียนอุปกรณ์ที่จับคู่แล้วในฐานข้อมูลสถานะ SQLite ของ Gateway:

- **การจับคู่อุปกรณ์** (บทบาท `node`) ควบคุมแฮนด์เชก `connect` ดู
  [การอนุมัติอุปกรณ์อัตโนมัติด้วย CIDR ที่เชื่อถือ](#trusted-cidr-device-auto-approval)
  ด้านล่างและ [การจับคู่ช่องทาง](/th/channels/pairing)
- **การอนุมัติความสามารถของ Node** (`node.pair.*`) ควบคุมว่า Node ที่เชื่อมต่อแล้วสามารถเปิดเผย
  ความสามารถ/คำสั่งใดที่ประกาศไว้ได้บ้าง Gateway เป็น
  แหล่งข้อมูลหลักที่เชื่อถือได้ ส่วน UI (แอป macOS, Control UI) เป็นส่วนหน้าที่ใช้อนุมัติหรือ
  ปฏิเสธคำขอที่รอดำเนินการ

ที่เก็บข้อมูลการจับคู่ Node แบบแยกต่างหากเดิม (`nodes/paired.json` พร้อมโทเค็นแยกต่อ Node
ซึ่งเลิกใช้งานในเส้นทางการเชื่อมต่อเมื่อเดือนมกราคม 2026) ถูกนำออกแล้ว: Gateway จะรวม
แถวข้อมูลที่ยังเหลืออยู่เข้าในระเบียนอุปกรณ์หนึ่งครั้งเมื่อเริ่มทำงาน และเก็บถาวร
ไฟล์แบบเก่าโดยเติมส่วนต่อท้าย `.migrated` ระบบรองรับบริดจ์ TCP แบบเก่าถูก
นำออกแล้ว

## การอนุมัติความสามารถทำงานอย่างไร

1. Node เชื่อมต่อกับ Gateway WS (การจับคู่อุปกรณ์ควบคุมขั้นตอนนี้)
2. Gateway เปรียบเทียบชุดความสามารถ/คำสั่งที่ประกาศกับชุดที่
   อนุมัติแล้ว หากเป็นชุดใหม่หรือมีขอบเขตกว้างขึ้น ระบบจะบันทึก **คำขอที่รอดำเนินการ** ไว้ใน
   ระเบียนอุปกรณ์และส่งเหตุการณ์ `node.pair.requested`
3. คุณอนุมัติหรือปฏิเสธคำขอ (ผ่าน CLI หรือ UI)
4. จนกว่าจะอนุมัติ คำสั่งของ Node จะยังถูกกรองอยู่ เมื่ออนุมัติแล้ว ชุดที่ประกาศไว้จะถูกเปิดเผย
   ภายใต้นโยบายคำสั่งปกติ

คำขอที่รอดำเนินการจะหมดอายุโดยอัตโนมัติ **5 นาทีหลังจากการลองใหม่ครั้งล่าสุดของ Node**
— Node ที่กำลังเชื่อมต่อใหม่อย่างต่อเนื่องจะคงคำขอที่รอดำเนินการรายการเดิมไว้
แทนที่จะสร้างคำขอใหม่ (และข้อความแจ้งให้อนุมัติ) ทุกครั้งที่ลอง

## ขั้นตอนการทำงานผ่าน CLI (เหมาะสำหรับระบบไร้ส่วนติดต่อ)

```bash
openclaw nodes pending
openclaw nodes approve <requestId>
openclaw nodes reject <requestId>
openclaw nodes status
openclaw nodes remove --node <id|name|ip>
openclaw nodes rename --node <id|name|ip> --name "Living Room iPad"
```

`nodes status` แสดง Node ที่จับคู่แล้ว/เชื่อมต่ออยู่และความสามารถของแต่ละ Node

## พื้นผิว API (โปรโตคอล Gateway)

เหตุการณ์:

- `node.pair.requested` - ส่งเมื่อมีการสร้างคำขอที่รอดำเนินการใหม่
- `node.pair.resolved` - ส่งเมื่อคำขอได้รับการอนุมัติ ถูกปฏิเสธ หรือ
  หมดอายุ

เมธอด:

- `node.pair.list` - แสดงรายการ Node ที่รอดำเนินการและจับคู่แล้ว (`operator.pairing`)
- `node.pair.approve` - อนุมัติคำขอที่รอดำเนินการ
- `node.pair.reject` - ปฏิเสธคำขอที่รอดำเนินการ
- `node.pair.remove` - นำ Node ที่จับคู่แล้วออก การดำเนินการนี้จะเพิกถอนบทบาท `node`
  ของอุปกรณ์ในที่เก็บอุปกรณ์ที่จับคู่แล้ว นำชุดพื้นผิว Node ที่อนุมัติแล้วออกไปพร้อมกัน และ
  ทำให้เซสชันบทบาท Node ของอุปกรณ์นั้นใช้การไม่ได้/ตัดการเชื่อมต่อ อุปกรณ์แบบ **หลายบทบาท**
  (เช่น อุปกรณ์ที่มีบทบาท `operator` ด้วย) จะยังคงมีแถวข้อมูลอยู่และสูญเสียเฉพาะ
  บทบาท `node` ส่วนแถวข้อมูลของอุปกรณ์ที่มีเฉพาะบทบาท Node จะถูกลบ การอนุญาต:
  `operator.pairing` สามารถนำแถว Node ที่ไม่ใช่โอเปอเรเตอร์ออกได้ ส่วนผู้เรียกที่ใช้โทเค็นอุปกรณ์
  และเพิกถอนบทบาท Node **ของตนเอง** บนอุปกรณ์แบบหลายบทบาทจะต้องมี
  `operator.admin` เพิ่มเติม
- `node.rename` - เปลี่ยนชื่อที่แสดงต่อโอเปอเรเตอร์ของ Node ที่จับคู่แล้ว

นำออกใน 2026.7: `node.pair.request` และ `node.pair.verify` คำขอที่รอดำเนินการ
สร้างโดย Gateway เองระหว่างการเชื่อมต่อของ Node และ
โทเค็นแยกต่อ Node ที่เมธอดเหล่านี้เคยรองรับไม่มีอยู่อีกต่อไป การยืนยันตัวตนของ Node ใช้
โทเค็นการจับคู่อุปกรณ์

หมายเหตุ:

- การเชื่อมต่อใหม่ที่มีชุดพื้นผิวไม่เปลี่ยนแปลงจะใช้คำขอที่รอดำเนินการเดิมซ้ำ คำขอซ้ำ
  จะรีเฟรชข้อมูลเมตาของ Node ที่จัดเก็บไว้และสแนปช็อตคำสั่งที่ประกาศล่าสุดซึ่งอยู่ในรายการอนุญาต
  เพื่อให้โอเปอเรเตอร์มองเห็น
- ระดับขอบเขตของโอเปอเรเตอร์และการตรวจสอบขณะอนุมัติสรุปไว้ใน
  [ขอบเขตของโอเปอเรเตอร์](/th/gateway/operator-scopes)
- `node.pair.approve` ใช้คำสั่งที่ประกาศในคำขอที่รอดำเนินการเพื่อบังคับใช้
  ขอบเขตการอนุมัติเพิ่มเติม:
  - คำขอที่ไม่มีคำสั่ง: `operator.pairing`
  - คำขอคำสั่งที่ไม่ใช่การเรียกใช้: `operator.pairing` + `operator.write`
  - คำขอ `system.run` / `system.run.prepare` / `system.which`:
    `operator.pairing` + `operator.admin`

<Warning>
การอนุมัติการจับคู่ Node จะบันทึกชุดความสามารถที่เชื่อถือ การดำเนินการนี้ **ไม่ได้** ตรึงชุดคำสั่งที่ใช้งานจริงของ Node แยกตามแต่ละ Node

- คำสั่ง Node ที่ใช้งานจริงมาจากสิ่งที่ Node ประกาศเมื่อเชื่อมต่อ โดยกรองตาม
  นโยบายคำสั่ง Node ส่วนกลางของ Gateway (`gateway.nodes.allowCommands` และ
  `denyCommands`)
- นโยบายอนุญาตและถามสำหรับ `system.run` แยกตาม Node จะอยู่บน Node ใน
  `exec.approvals.node.*` ไม่ได้อยู่ในระเบียนการจับคู่

</Warning>

## การควบคุมคำสั่ง Node (2026.3.31+)

<Warning>
**การเปลี่ยนแปลงที่เข้ากันไม่ได้:** ตั้งแต่ `2026.3.31` เป็นต้นไป คำสั่ง Node จะถูกปิดใช้งานจนกว่าจะอนุมัติการจับคู่ Node การจับคู่อุปกรณ์เพียงอย่างเดียวไม่เพียงพอที่จะเปิดเผยคำสั่ง Node ที่ประกาศไว้อีกต่อไป
</Warning>

เมื่อ Node เชื่อมต่อเป็นครั้งแรก ระบบจะขอจับคู่โดยอัตโนมัติ
จนกว่าคำขอนั้นจะได้รับการอนุมัติ คำสั่ง Node ที่รอดำเนินการทั้งหมดจาก Node นั้นจะถูก
กรองและจะไม่ถูกเรียกใช้ เมื่อการจับคู่ได้รับการอนุมัติ คำสั่งที่ Node ประกาศไว้
จะพร้อมใช้งานภายใต้นโยบายคำสั่งปกติ

ซึ่งหมายความว่า:

- Node ที่ก่อนหน้านี้อาศัยเพียงการจับคู่อุปกรณ์เพื่อเปิดเผยคำสั่ง จะต้อง
  ดำเนินการจับคู่ Node ให้เสร็จสมบูรณ์ด้วย
- คำสั่งที่เข้าคิวไว้ก่อนการอนุมัติการจับคู่จะถูกทิ้ง ไม่ได้เลื่อนการทำงานออกไป

## ขอบเขตความเชื่อถือของเหตุการณ์ Node (2026.3.31+)

<Warning>
**การเปลี่ยนแปลงที่เข้ากันไม่ได้:** ขณะนี้การเรียกใช้ที่เริ่มจาก Node จะจำกัดอยู่ในชุดพื้นผิวที่เชื่อถือซึ่งลดขอบเขตลง
</Warning>

ข้อมูลสรุปที่เริ่มจาก Node และเหตุการณ์เซสชันที่เกี่ยวข้องจะถูกจำกัดไว้เฉพาะ
ชุดพื้นผิวที่เชื่อถือตามวัตถุประสงค์ ขั้นตอนการทำงานที่ขับเคลื่อนด้วยการแจ้งเตือนหรือเรียกโดย Node ซึ่ง
ก่อนหน้านี้อาศัยการเข้าถึงเครื่องโฮสต์หรือเครื่องมือเซสชันที่กว้างกว่า อาจต้องปรับเปลี่ยน
การเสริมความปลอดภัยนี้ป้องกันไม่ให้เหตุการณ์ Node ยกระดับไปสู่การเข้าถึงเครื่องมือระดับโฮสต์
เกินกว่าที่ขอบเขตความเชื่อถือของ Node อนุญาต

การอัปเดตสถานะการออนไลน์ของ Node แบบคงทนใช้ขอบเขตข้อมูลประจำตัวเดียวกัน:
เหตุการณ์ `node.presence.alive` จะได้รับการยอมรับเฉพาะจากเซสชันอุปกรณ์ Node ที่ผ่านการยืนยันตัวตน
และจะอัปเดตข้อมูลเมตาการจับคู่เฉพาะเมื่อข้อมูลประจำตัวของอุปกรณ์/Node
จับคู่ไว้แล้ว ค่า `client.id` ที่ประกาศโดยตัวเองไม่เพียงพอสำหรับเขียน
สถานะการพบเห็นล่าสุด

## การอนุมัติอุปกรณ์อัตโนมัติที่ตรวจสอบผ่าน SSH (ค่าเริ่มต้น)

การจับคู่อุปกรณ์ `role: node` ครั้งแรกจากที่อยู่ส่วนตัว/CGNAT จะได้รับ
การอนุมัติอัตโนมัติเมื่อ Gateway สามารถ **พิสูจน์ความเป็นเจ้าของเครื่องผ่าน SSH** ได้ โดย Gateway จะ
เชื่อมต่อกลับไปยังโฮสต์ที่ขอจับคู่ (`BatchMode`, `StrictHostKeyChecking=yes`)
เรียกใช้ `openclaw node identity --json` ที่นั่น และอนุมัติเฉพาะเมื่อรหัสอุปกรณ์ระยะไกล
และกุญแจสาธารณะตรงกับคำขอที่รอดำเนินการทุกประการ การตรวจสอบว่ากุญแจตรงกัน
คือสิ่งที่ทำให้กระบวนการนี้ปลอดภัย: การเข้าถึงได้เพียงอย่างเดียวจะไม่ทำให้ได้รับอนุมัติ ดังนั้นผู้เช่าร่วมหลัง NAT,
ผู้ใช้อื่นบนโฮสต์ที่ใช้ร่วมกัน และการปลอมแปลงบน LAN ทั้งหมดจะย้อนกลับไปใช้
ข้อความแจ้งปกติ

เปิดใช้งานโดยค่าเริ่มต้น ข้อกำหนดเพื่อให้ทำงาน:

- ผู้ใช้ของโพรเซส Gateway (หรือ `sshVerify.user`) สามารถเชื่อมต่อ SSH ไปยังโฮสต์ Node
  แบบไม่โต้ตอบได้ (ใช้กุญแจ/เอเจนต์ และ Tailscale SSH ก็ใช้ได้) และกุญแจโฮสต์
  ได้รับความเชื่อถือแล้ว
- `openclaw` สามารถค้นพบได้ใน `PATH` ระยะไกลสำหรับ `sh -lc` แบบไม่โต้ตอบ
- IP ที่เชื่อมต่อเป็นที่อยู่ส่วนตัว, ULA, ลิงก์เฉพาะที่ หรือ CGNAT โดยตรง
  (ไม่ผ่านพร็อกซีและไม่ใช่ local loopback) หรือตรงกับ `sshVerify.cidrs` หากตั้งค่าไว้
- ใช้เกณฑ์คุณสมบัติขั้นต่ำเดียวกับการอนุมัติด้วย CIDR ที่เชื่อถือ: เฉพาะการจับคู่ Node ใหม่
  ที่ไม่มีขอบเขตเท่านั้น การอัปเกรด เบราว์เซอร์ Control UI และ WebChat จะแสดงข้อความแจ้งเสมอ

ระหว่างที่โพรบกำลังทำงาน ไคลเอนต์ Node จะได้รับคำสั่งให้ลองใหม่ต่อไป
(`wait_then_retry`) แทนที่จะหยุดรอการอนุมัติด้วยตนเอง หากโพรบ
ล้มเหลว ความพยายามครั้งถัดไปจะย้อนกลับไปใช้ขั้นตอนข้อความแจ้งปกติ เป้าหมายที่ล้มเหลว
จะถูกพักชั่วคราวช่วงสั้น ๆ (5 นาทีหลังจากกุญแจไม่ตรงกัน)

อุปกรณ์ที่ได้รับอนุมัติจะบันทึก `approvedVia: "ssh-verified"` และชุด
ความสามารถที่ประกาศครั้งแรกจะได้รับอนุมัติในขั้นตอนเดียวกัน — การที่กุญแจตรงกันพิสูจน์แล้วว่า
Node ทำงานภายใต้บัญชีของโอเปอเรเตอร์บนเครื่องที่โอเปอเรเตอร์เป็นเจ้าของ ซึ่งเป็น
ข้อยืนยันเดียวกับที่การอนุมัติความสามารถด้วยตนเองให้ไว้ การขยายชุดพื้นผิวในภายหลังจะยังคง
แสดงข้อความแจ้ง

เสริมความปลอดภัยหรือปิดใช้งาน:

```json5
{
  gateway: {
    nodes: {
      pairing: {
        // Disable entirely:
        sshVerify: false,
        // ...or scope/tune the probe:
        // sshVerify: { user: "me", identity: "~/.ssh/probe", timeoutMs: 7000, cidrs: ["10.0.0.0/8"] },
      },
    },
  },
}
```

## การอนุมัติอัตโนมัติ (แอป macOS)

แอป macOS สามารถพยายาม **อนุมัติแบบเงียบ** สำหรับคำขอความสามารถของ Node
เมื่อ:

- คำขอถูกระบุเป็น `silent` (Gateway จะระบุชุดความสามารถแรก
  เป็นแบบเงียบเมื่อการจับคู่อุปกรณ์ได้รับการอนุมัติแบบไม่โต้ตอบ) และ
- แอปสามารถตรวจสอบการเชื่อมต่อ SSH ไปยังโฮสต์ Gateway โดยใช้ผู้ใช้
  คนเดียวกัน

หากการอนุมัติแบบเงียบล้มเหลว ระบบจะย้อนกลับไปใช้ข้อความแจ้ง Approve/Reject ตามปกติ

## การอนุมัติอุปกรณ์อัตโนมัติด้วย CIDR ที่เชื่อถือ

การจับคู่อุปกรณ์ WS สำหรับ `role: node` ยังคงเป็นแบบดำเนินการด้วยตนเองโดยค่าเริ่มต้น สำหรับเครือข่าย Node
ส่วนตัวที่ Gateway เชื่อถือเส้นทางเครือข่ายอยู่แล้ว โอเปอเรเตอร์สามารถเลือกเปิดใช้
ด้วย CIDR หรือ IP แบบเจาะจงอย่างชัดเจน:

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

ขอบเขตความปลอดภัย:

- ปิดใช้งานเมื่อไม่ได้ตั้งค่า `gateway.nodes.pairing.autoApproveCidrs`
- ไม่มีโหมดอนุมัติอัตโนมัติแบบครอบคลุมทั้ง LAN หรือเครือข่ายส่วนตัว การอนุมัติอัตโนมัติที่
  ตรวจสอบผ่าน SSH (ด้านบน) ต้องอาศัยกุญแจอุปกรณ์ที่ตรงกันในเชิงเข้ารหัส และไม่ใช้
  เพียงตำแหน่งบนเครือข่าย
- มีสิทธิ์เฉพาะคำขอจับคู่อุปกรณ์ `role: node` ใหม่ที่ไม่มีขอบเขตที่ร้องขอ
- ไคลเอนต์โอเปอเรเตอร์ เบราว์เซอร์ Control UI และ WebChat ยังคงต้องดำเนินการด้วยตนเอง
- การอัปเกรดบทบาท ขอบเขต ข้อมูลเมตา และกุญแจสาธารณะยังคงต้องดำเนินการด้วยตนเอง
- เส้นทางส่วนหัวพร็อกซีที่เชื่อถือผ่าน local loopback บนโฮสต์เดียวกันไม่มีสิทธิ์
  เนื่องจากผู้เรียกในเครื่องสามารถปลอมแปลงเส้นทางดังกล่าวได้

## การล้างข้อมูลการจับคู่แบบเงียบที่ถูกแทนที่

การอนุมัติแบบไม่โต้ตอบจะบันทึกที่มาบนแถวอุปกรณ์ที่จับคู่แล้ว:
การอนุมัติตามนโยบายภายในโฮสต์เดียวกันเป็น `silent` การอนุมัติ Node ด้วย CIDR ที่เชื่อถือเป็น
`trusted-cidr` และการอนุมัติ Node ที่ตรวจสอบผ่าน SSH เป็น `ssh-verified` ไคลเอนต์ที่มีไดเรกทอรีสถานะชั่วคราว (โฮมชั่วคราว,
คอนเทนเนอร์, แซนด์บ็อกซ์แยกต่อการเรียกใช้) จะสร้างคู่กุญแจอุปกรณ์ใหม่ทุกครั้งที่ทำงาน และทุก
การทำงานจะจับคู่ใหม่แบบเงียบในฐานะอุปกรณ์ใหม่เอี่ยม หากไม่มีการล้างข้อมูล รายการอุปกรณ์ที่จับคู่แล้ว
จะเพิ่มแถวเก่าที่ไม่ใช้งานหนึ่งแถวต่อการทำงานแต่ละครั้ง

เมื่อ Gateway อนุมัติการจับคู่อุปกรณ์ **ภายในเครื่อง** แบบเงียบ ระบบจะเลิกใช้
ระเบียนเก่าที่อนุมัติแบบ `silent` ซึ่งอยู่ในคลัสเตอร์ไคลเอนต์เดียวกัน
(ตรงกันตาม `clientId`, `clientMode` และชื่อที่แสดง) และไม่ได้เชื่อมต่ออยู่ในขณะนั้น
ไคลเอนต์ภายในเครื่องทำงานบนโฮสต์ Gateway เอง ดังนั้นคีย์คลัสเตอร์
จึงไม่สามารถตรงกับเครื่องอื่นได้ แถวที่เลิกใช้จะสูญเสียโทเค็นทันที
รายการจับคู่ Node แบบเก่าที่ตรงกันจะถูกล้าง และระบบจะกระจายเหตุการณ์การนำออก
`node.pair.resolved`

ขอบเขต:

- เฉพาะระเบียนที่การอนุมัติล่าสุดเป็นแบบภายในโฮสต์เดียวกัน (`silent`) เท่านั้นที่
  มีสิทธิ์ ทั้งในฐานะตัวกระตุ้นและเป้าหมาย การจับคู่ด้วย CIDR ที่เชื่อถือและการจับคู่ที่ตรวจสอบผ่าน SSH
  เกิดข้ามโฮสต์ ซึ่งข้อมูลเมตาที่แสดงไม่ใช่ข้อมูลประจำตัวของเครื่อง จึง
  ไม่ถูกนำออกโดยอัตโนมัติ — ให้ใช้การล้างข้อมูลใน Control UI หรือ
  `openclaw nodes remove` สำหรับระเบียนเหล่านั้น
- การจับคู่ที่เจ้าของอนุมัติและการจับคู่ด้วย QR/รหัสตั้งค่า (บูตสแตรป) จะไม่ถูกนำออก
  โดยอัตโนมัติ ระเบียนที่อนุมัติก่อนมีข้อมูลที่มาจะยังได้รับการปกป้อง
  แม้ภายหลังจะมีการอนุมัติแบบเงียบอีกครั้งสำหรับรหัสอุปกรณ์เดียวกัน
- อุปกรณ์ที่กำลังเชื่อมต่อจะถูกข้าม ดังนั้นเซสชันภายในเครื่องที่ทำงานพร้อมกันโดยใช้
  ไดเรกทอรีสถานะแยกกันจะยังคงมีโทเค็นขณะใช้งาน ระเบียนที่ได้รับอนุมัติ
  ภายในหนึ่งนาทีล่าสุดจะถูกข้ามเช่นกัน เพื่อไม่ให้แฮนด์เชกการจับคู่ที่เกิดขึ้นพร้อมกัน
  เลิกใช้กันเองก่อนที่การเชื่อมต่อจะลงทะเบียน
- ไคลเอนต์ที่ได้รับผลกระทบเป็นไคลเอนต์ภายในเครื่องตามโครงสร้าง จึงจะจับคู่ใหม่แบบเงียบเมื่อ
  เชื่อมต่อครั้งถัดไป

## การอนุมัติอัตโนมัติสำหรับการอัปเกรดข้อมูลเมตา

เมื่ออุปกรณ์ที่จับคู่แล้วเชื่อมต่อใหม่โดยมีเฉพาะการเปลี่ยนแปลงข้อมูลเมตา
ที่ไม่ละเอียดอ่อน (เช่น ชื่อที่แสดงหรือคำใบ้แพลตฟอร์มไคลเอนต์) OpenClaw จะถือว่า
เป็น `metadata-upgrade` การอนุมัติอัตโนมัติแบบเงียบมีขอบเขตจำกัด โดยใช้เฉพาะ
การเชื่อมต่อใหม่ภายในเครื่องที่เชื่อถือและไม่ใช่เบราว์เซอร์ ซึ่งได้พิสูจน์การครอบครอง
ข้อมูลรับรองภายในเครื่องหรือที่ใช้ร่วมกันแล้ว รวมถึงการเชื่อมต่อใหม่ของแอปเนทีฟบนโฮสต์เดียวกันหลังจาก
ข้อมูลเมตาเวอร์ชันระบบปฏิบัติการเปลี่ยนแปลง ไคลเอนต์เบราว์เซอร์/Control UI และไคลเอนต์ระยะไกล
ยังคงใช้ขั้นตอนการอนุมัติใหม่อย่างชัดเจน การอัปเกรดขอบเขต (จากอ่านเป็น
เขียน/ผู้ดูแลระบบ) และการเปลี่ยนแปลงกุญแจสาธารณะ **ไม่มี** สิทธิ์รับ
การอนุมัติอัตโนมัติสำหรับการอัปเกรดข้อมูลเมตา แต่ยังคงเป็นคำขออนุมัติใหม่อย่างชัดเจน

## ตัวช่วยการจับคู่ด้วย QR

`/pair qr` แสดงเพย์โหลดการจับคู่เป็นสื่อที่มีโครงสร้าง เพื่อให้ไคลเอนต์บนอุปกรณ์เคลื่อนที่และเบราว์เซอร์สแกนได้โดยตรง

การลบอุปกรณ์จะล้างคำขอจับคู่ที่รอดำเนินการและค้างอยู่ทั้งหมดของรหัสอุปกรณ์นั้นด้วย ดังนั้น `nodes pending` จะไม่แสดงแถวกำพร้าหลังจากเพิกถอน

## ตำแหน่งการเชื่อมต่อและส่วนหัวที่ส่งต่อ

การจับคู่ของ Gateway จะถือว่าการเชื่อมต่อเป็น local loopback เฉพาะเมื่อทั้งซ็อกเก็ตดิบและหลักฐานจากพร็อกซีต้นทางทั้งหมดสอดคล้องกัน หากคำขอมาถึงผ่าน local loopback แต่มีหลักฐานจากส่วนหัว `Forwarded`, `X-Forwarded-*` ใด ๆ หรือ `X-Real-IP` หลักฐานจากส่วนหัวที่ส่งต่อนั้นจะทำให้การอ้างว่าเป็นการเชื่อมต่อภายใน local loopback ใช้ไม่ได้ และเส้นทางการจับคู่จะต้องได้รับการอนุมัติอย่างชัดเจน แทนที่จะถือโดยปริยายว่าคำขอนั้นเป็นการเชื่อมต่อจากโฮสต์เดียวกัน โปรดดู [การยืนยันตัวตนผ่านพร็อกซีที่เชื่อถือได้](/th/gateway/trusted-proxy-auth) สำหรับกฎที่เทียบเท่ากันในการยืนยันตัวตนของผู้ดำเนินการ

## พื้นที่จัดเก็บ (ภายในเครื่องและเป็นส่วนตัว)

สถานะการจับคู่จะอยู่ในระเบียนอุปกรณ์ที่จับคู่ภายในฐานข้อมูลสถานะ SQLite ที่ใช้ร่วมกัน ซึ่งอยู่ใต้ไดเรกทอรีสถานะของ Gateway (ค่าเริ่มต้นคือ `~/.openclaw`):

- `~/.openclaw/state/openclaw.sqlite` (อุปกรณ์ที่จับคู่พร้อมข้อมูลยืนยันตัวตนของอุปกรณ์, พื้นผิวของ Node ที่ได้รับอนุมัติ, คำขอพื้นผิวที่รอดำเนินการ, คำขอจับคู่อุปกรณ์ที่รอดำเนินการ และโทเค็นเริ่มต้นระบบ)

หากคุณกำหนดค่าแทนที่ `OPENCLAW_STATE_DIR` ฐานข้อมูลจะย้ายตามไปด้วย Gateway ที่อัปเกรดจากรุ่นที่ใช้พื้นที่จัดเก็บ JSON จะนำเข้าข้อมูลเหล่านั้นเมื่อเริ่มต้นระบบ และเก็บไฟล์สำรอง `devices/*.json.migrated` และ `nodes/*.json.migrated` ไว้

หมายเหตุด้านความปลอดภัย:

- โทเค็นของอุปกรณ์เป็นข้อมูลลับ โปรดถือว่าฐานข้อมูลสถานะเป็นข้อมูลละเอียดอ่อน
- การหมุนเวียนโทเค็นของอุปกรณ์ใช้ `openclaw devices rotate` / `device.token.rotate`

## ลักษณะการทำงานของการรับส่งข้อมูล

- การรับส่งข้อมูลเป็นแบบ **ไร้สถานะ** โดยไม่จัดเก็บข้อมูลสมาชิก
- หาก Gateway ออฟไลน์หรือปิดใช้งานการจับคู่ Node จะไม่สามารถจับคู่ได้
- ในโหมดระยะไกล การจับคู่จะดำเนินการกับพื้นที่จัดเก็บของ Gateway ระยะไกล

## เนื้อหาที่เกี่ยวข้อง

- [การจับคู่ช่องทาง](/th/channels/pairing)
- [CLI สำหรับ Node](/th/cli/nodes)
- [CLI สำหรับอุปกรณ์](/th/cli/devices)