การจับคู่ Node

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

• การจับคู่อุปกรณ์ (บทบาท node) ควบคุมการจับมือ connect ดู การอนุมัติอุปกรณ์อัตโนมัติด้วย CIDR ที่เชื่อถือ ด้านล่างและ การจับคู่ช่องทาง
• การอนุมัติความสามารถของ Node (node.pair.*) ควบคุมว่า Node ที่เชื่อมต่อจะเปิดเผย ความสามารถ/คำสั่งใดที่ประกาศไว้ได้บ้าง Gateway เป็น แหล่งข้อมูลจริง ส่วน UI (แอป macOS, Control UI) เป็นส่วนหน้าที่อนุมัติหรือ ปฏิเสธคำขอที่รอดำเนินการ

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

วิธีทำงานของการอนุมัติความสามารถ

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

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

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

openclaw nodes pendingopenclaw nodes approve <requestId>openclaw nodes reject <requestId>openclaw nodes statusopenclaw 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 ที่จัดเก็บไว้และสแนปช็อตคำสั่งที่ประกาศ ซึ่งอยู่ในรายการอนุญาตล่าสุด เพื่อให้ผู้ปฏิบัติงานมองเห็น
• ระดับขอบเขตของผู้ปฏิบัติงานและการตรวจสอบขณะอนุมัติสรุปไว้ใน ขอบเขตของผู้ปฏิบัติงาน
• node.pair.approve ใช้คำสั่งที่ประกาศไว้ในคำขอที่รอดำเนินการเพื่อบังคับใช้ ขอบเขตการอนุมัติเพิ่มเติม:
  • คำขอที่ไม่มีคำสั่ง: operator.pairing
  • คำขอคำสั่งทั่วไป: operator.pairing + operator.write
  • คำขอที่มีความอ่อนไหวระดับผู้ดูแลระบบซึ่งประกอบด้วย system.run, system.run.prepare, system.which, browser.proxy, fs.listDir หรือ system.execApprovals.get/set: operator.pairing + operator.admin

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

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

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

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

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

ข้อมูลสรุปที่เริ่มจาก 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, link-local หรือ CGNAT โดยตรง (ไม่ผ่านพร็อกซีและไม่ใช่ลูปแบ็ก) หรือตรงกับ sshVerify.cidrs เมื่อตั้งค่าไว้
• ใช้เกณฑ์คุณสมบัติขั้นต่ำเดียวกับการอนุมัติด้วย CIDR ที่เชื่อถือ: เฉพาะการจับคู่ Node ใหม่ที่ไม่มีขอบเขตเท่านั้น การอัปเกรด เบราว์เซอร์ Control UI และ WebChat จะแสดงข้อความแจ้งเสมอ

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

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

เพิ่มความเข้มงวดหรือปิดใช้งาน:

{  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 ที่ระบุอย่างชัดเจน:

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

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

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

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

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

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

ขอบเขต:

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

การอนุมัติอัตโนมัติเมื่ออัปเกรดข้อมูลเมตา

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

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

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

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

ความเป็นภายในเครื่องและส่วนหัวที่ส่งต่อ

การจับคู่ของ Gateway จะถือว่าการเชื่อมต่อเป็นลูปแบ็กก็ต่อเมื่อทั้งซ็อกเก็ตดิบ และหลักฐานจากพร็อกซีต้นทางทั้งหมดสอดคล้องกัน หากคำขอมาถึงผ่านลูปแบ็กแต่ มีหลักฐานส่วนหัว Forwarded, X-Forwarded-* ใด ๆ หรือ X-Real-IP หลักฐานส่วนหัวที่ส่งต่อนั้นจะทำให้คำกล่าวอ้างว่าเป็นการเชื่อมต่อภายในเครื่องแบบลูปแบ็กใช้ไม่ได้ และ เส้นทางการจับคู่จะต้องได้รับการอนุมัติแบบชัดแจ้ง แทนที่จะถือว่าคำขอ เป็นการเชื่อมต่อจากโฮสต์เดียวกันโดยอัตโนมัติ ดูกฎที่เทียบเท่ากันสำหรับ การตรวจสอบสิทธิ์ของผู้ปฏิบัติงานได้ที่ การตรวจสอบสิทธิ์ผ่านพร็อกซีที่เชื่อถือได้

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

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

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

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

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

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

ลักษณะการทำงานของการขนส่ง

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

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

• การจับคู่ช่องทาง
• CLI สำหรับ Node
• CLI สำหรับอุปกรณ์