การจับคู่ 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 เชื่อมต่อกับ Gateway WS (การจับคู่อุปกรณ์ควบคุมขั้นตอนนี้)
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: 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, ลิงก์เฉพาะที่ หรือ CGNAT โดยตรง (ไม่ผ่านพร็อกซีและไม่ใช่ local loopback) หรือตรงกับ 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 ยังคงต้องดำเนินการด้วยตนเอง
• การอัปเกรดบทบาท ขอบเขต ข้อมูลเมตา และกุญแจสาธารณะยังคงต้องดำเนินการด้วยตนเอง
• เส้นทางส่วนหัวพร็อกซีที่เชื่อถือผ่าน 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 ใช้ไม่ได้ และเส้นทางการจับคู่จะต้องได้รับการอนุมัติอย่างชัดเจน แทนที่จะถือโดยปริยายว่าคำขอนั้นเป็นการเชื่อมต่อจากโฮสต์เดียวกัน โปรดดู การยืนยันตัวตนผ่านพร็อกซีที่เชื่อถือได้ สำหรับกฎที่เทียบเท่ากันในการยืนยันตัวตนของผู้ดำเนินการ

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

สถานะการจับคู่จะอยู่ในระเบียนอุปกรณ์ที่จับคู่ภายในฐานข้อมูลสถานะ 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 ระยะไกล

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

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