โฮสต์ Open Connector เองสำหรับ AI agent บน VPS

Open Connector ทำอะไรให้กับ AI agent

การโฮสต์ Open Connector เองจะวาง auth gateway ไว้ระหว่าง AI agent ของคุณกับ API แบบ software as a service (SaaS) ทุกตัวที่ agent เรียกใช้ ทำให้ agent ไม่ต้องเก็บ provider token ไว้ Open Connector เป็น gateway แบบ open source จาก OOMOL Lab และใช้สัญญาอนุญาต Apache 2.0 ระบบทำงานเป็น container เดียว เก็บสถานะไว้ในไฟล์ SQLite เดียว และเผยแพร่การทำงานของ provider ผ่าน HTTP และ MCP (model context protocol)

ปัญหาจะเริ่มขึ้นเมื่อต้องเชื่อมต่อระบบที่ 2 provider แต่ละรายมีขั้นตอน OAuth (open authorization) อายุของ refresh token และชื่อ scope ของตนเอง การเชื่อมต่อ provider 5 รายเข้ากับ agent ด้วยตนเองหมายถึงต้องมี redirect handler 5 ชุด ที่เก็บข้อมูลรับรอง 5 ชุด และ refresh loop 5 ชุด ซึ่งต้องทำงานก่อนที่ token จะหมดอายุ แทบไม่มีใครเขียนโค้ดส่วนนี้เอง ผู้ดูแลระบบจึงมักสร้าง personal access token ที่มีอายุยาว 1 รายการต่อบริการ แล้วนำไปใส่ในการตั้งค่าของ agent ไฟล์ environment หรือ prompt token ดังกล่าวจะอ่านได้โดยทุก tool ที่ agent เรียกใช้ และจะถูกบันทึกลงใน transcript ด้วย ซึ่งเป็นปัญหาที่อธิบายไว้ใน การป้องกันข้อมูลลับไม่ให้รั่วไหลไปยัง AI agent

auth gateway แยก credential ออกเป็น 2 ส่วน gateway จะเก็บ credential ของ provider และดำเนินขั้นตอน OAuth ส่วน agent จะได้รับ runtime token ที่ใช้ได้เฉพาะกับ gateway เมื่อ agent เรียก action, gateway จะโหลด credential ที่จัดเก็บไว้ ใส่ credential นั้นลงในคำขอขาออกที่ฝั่ง server และส่งกลับเฉพาะ response body agent จะไม่ได้รับ provider access token ดังนั้นหาก transcript ของ agent รั่วไหล ความเสียหายจะจำกัดอยู่ที่ runtime token 1 รายการที่เพิกถอนได้ แทนที่จะกระทบทั้งบัญชี GitHub ของคุณ

แค็ตตาล็อกระบุว่ารองรับ provider มากกว่า 1,000 รายและ action ที่สร้างไว้ล่วงหน้ามากกว่า 10,000 รายการ ตัวเลขนี้เป็นข้อมูลของโครงการเอง และไม่ใช่สิ่งที่คุณตรวจสอบจากภายนอกได้ สิ่งที่ตรวจสอบได้คือโครงสร้างของระบบ ได้แก่ HTTP endpoint 1 รายการต่อ action, connection ที่จัดเก็บไว้ 1 รายการต่อ provider และ token 1 รายการต่อ agent

เหตุผลที่ควรโฮสต์ Open Connector ด้วยตนเองแทนการใช้บริการ connector ที่โฮสต์ให้

บริการ connector ที่โฮสต์ให้ทำงานแบบเดียวกัน และเก็บ refresh tokens ของผู้ให้บริการทุกรายที่คุณเชื่อมต่อไว้ refresh token ของ Google หรือ GitHub เป็นคีย์เข้ารหัสอายุยาวที่ใช้เข้าถึงอีเมลและ repository ของคุณ และโดยปกติยังใช้ได้แม้เปลี่ยนรหัสผ่านแล้ว หากระบบของบริการถูกเจาะ ระบบของคุณก็จะได้รับผลกระทบด้วย การโฮสต์ด้วยตนเองจะย้ายข้อมูลเหล่านี้ไปไว้ใน SQLite บนเครื่องที่คุณเช่าและดูแลเอง พร้อมป้องกันด้วยคีย์ที่ไม่เคยออกจากเครื่องของคุณ

พิจารณาต้นทุนและความเสี่ยงให้ชัดเจนก่อนเริ่ม VPS นี้จะกลายเป็นเซิร์ฟเวอร์ที่มีค่าที่สุดที่คุณดูแลอยู่ เครื่องนี้เก็บข้อมูลรับรองที่ใช้งานได้ของบริการหลายสิบรายการไว้ในไฟล์เดียว จึงต้องดูแลในระดับเดียวกับโฮสต์ที่ใช้เก็บ password manager ได้แก่ ตั้งค่าไฟร์วอลล์ให้เปิดเผยเฉพาะ 443 ไม่ใช้บัญชีร่วม มีข้อมูลสำรองที่คุณเคยกู้คืนสำเร็จแล้วอย่างน้อย 1 ครั้ง และตั้งการแจ้งเตือนเมื่อเซิร์ฟเวอร์หยุดตอบสนอง หากคุณจะไม่เก็บคลังรหัสผ่านไว้บนเครื่องนี้ ก็ไม่ควรติดตั้ง connector ไว้บนเครื่องนี้เช่นกัน

ตรึงเวอร์ชันก่อนติดตั้งสิ่งใด

Open Connector ยังเป็นซอฟต์แวร์ใหม่ Repository นี้ปรากฏครั้งแรกเมื่อ 29 June 2026 และ ณ วันที่ 1 August 2026 รุ่นที่ติดแท็กล่าสุดคือ v1.3.3 ซึ่งเผยแพร่เมื่อ 30 July 2026 และมีแท็ก latest ด้วย Registry ยังเผยแพร่แท็ก tip ซึ่งสร้างจาก commit ล่าสุดบน main

แท็กที่เลื่อนไปตามการอัปเดตบนโครงการที่ยังใหม่เช่นนี้มักเปลี่ยนแปลงบ่อย docker compose pull ที่ข้ามไป 2 รุ่นอาจเปลี่ยน endpoint ที่ agent ของคุณต้องพึ่งพา และทำให้คุณใช้เวลาตลอดเย็นตรวจสอบปัญหาโดยเข้าใจผิดว่าเป็นปัญหาของ agent ให้ตรึง image ไว้ที่แท็กของรุ่น แล้วอัปเกรดเมื่อคุณตัดสินใจ หลังจากอ่าน release notes แล้ว

นำ Open Connector ไปใช้งานเบื้องหลัง TLS บน VPS ของคุณเอง

ก่อนเริ่มคอนเทนเนอร์ คุณต้องมีสิ่งต่อไปนี้:

• Docker พร้อมปลั๊กอิน Compose บน Ubuntu 24.04 หรือระบบที่ใกล้เคียง
• hostname ที่ระเบียน A ชี้มายัง VPS นี้ เช่น connect.example.com
• reverse proxy ที่ทำหน้าที่สิ้นสุดการเชื่อมต่อ TLS (transport layer security) สำหรับ hostname ดังกล่าวอยู่แล้ว
• secret แบบสุ่ม 2 ค่า ซึ่งจะสร้างในขั้นตอนถัดไป

คู่มือ reverse proxy Traefik สำหรับแอป Docker Compose หลายรายการ อธิบายส่วนของ proxy ส่วนการตั้งค่า certificate ตั้งแต่ต้นจนจบสำหรับแอปเดียว ดูได้จากคู่มือ n8n บน VPS ด้วย Docker และ HTTPS

สร้าง secret ก่อน โดย encryption key ใช้ปกป้อง credentials ที่จัดเก็บไว้ ส่วน admin token ใช้ป้องกัน web console และพื้นผิว /api ทั้งหมด ทั้งสองค่าไม่มีค่าเริ่มต้น และ runtime สามารถเริ่มทำงานได้โดยไม่มีค่าเหล่านี้

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

คัดลอกค่าทั้งสองไปเก็บใน password manager ทันที ก่อนเริ่มครั้งแรก encryption key ไม่มีวิธีกู้คืน และมีคำอธิบายเหตุผลในรายการข้อผิดพลาดด้านล่าง

จากนั้น compose.yaml ไฟล์นี้แตกต่างจากตัวอย่าง upstream อยู่ 2 จุด และทั้งสองจุดมีผลต่อการทำงาน

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

จุดแรกคือการระบุ tag แบบ pin แทน latest จุดที่สองคือ port ไฟล์ upstream เผยแพร่ 3000:3000 ซึ่ง bind กับทุก interface บน host Docker จะเขียน published ports ลงในตาราง NAT (network address translation) ก่อนที่ packet จะเข้าสู่ ufw filter chain ดังนั้น ufw deny 3000 จึงไม่ปิด port ดังกล่าว นี่คือกับดักที่อธิบายไว้ใน เหตุผลที่ Docker ports ข้าม ufw ได้ การเขียน 127.0.0.1:3000:3000 จะเผยแพร่ port เฉพาะบน loopback interface และ reverse proxy ของคุณจะเชื่อมต่อจาก host เดียวกัน

:? ระบุว่าตัวแปรแต่ละตัวเป็นค่าที่จำเป็น ดังนั้น stack จะปฏิเสธการเริ่มทำงานเมื่อไม่มี .env แทนที่จะเริ่มทำงานโดยเก็บ credentials แบบไม่เข้ารหัส การเก็บค่าเหล่านี้ไว้ใน .env แทนการใส่ไว้ใน compose file เป็นรูปแบบที่อธิบายไว้ใน ไฟล์ env และ secret ของ Docker Compose

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health ตอบ { "ok": true } เมื่อ runtime เริ่มทำงานแล้ว ss ต้องแสดง 127.0.0.1:3000 หากมีบรรทัดเป็น 0.0.0.0:3000 แสดงว่า port mapping ยังเป็นค่าจาก upstream และ gateway กำลังตอบรับการเชื่อมต่อจากอินเทอร์เน็ตโดยตรง หาก health check แสดง connection refused แสดงว่าคอนเทนเนอร์ยังไม่กำลัง listen อยู่ ดังนั้นให้อ่าน logs ก่อนแก้ไข proxy

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

เหตุผลที่ OAuth บังคับให้ต้องมี hostname จริง

OOMOL_CONNECT_ORIGIN คือการตั้งค่าที่มักถูกข้าม และการข้ามการตั้งค่านี้ทำให้ OAuth ทำงานล้มเหลวในลักษณะที่ดูเหมือนเป็นข้อบกพร่องของ provider runtime จะสร้าง redirect URI จาก origin ดังกล่าวในรูปแบบ <origin>/oauth/callback หากไม่ได้ตั้งค่า origin จะมีค่าเริ่มต้นเป็น http://localhost:3000 ดังนั้น runtime จะส่ง redirect URI เป็น http://localhost:3000/oauth/callback ให้ provider ขณะที่แอป OAuth ของคุณลงทะเบียนไว้เป็น https://connect.example.com/oauth/callback สตริงทั้งสองไม่ตรงกัน GitHub จึงตอบกลับว่า:

The redirect_uri MUST match the registered callback URL for this application.

OAuth provider จะ redirect เบราว์เซอร์กลับไปยัง URI ดังกล่าว ซึ่งหมายความว่า URI นั้นต้องเป็นที่อยู่ที่เครือข่ายภายนอกเข้าถึงได้ และ provider จะปฏิเสธ http:// แบบไม่เข้ารหัสสำหรับทุกกรณี ยกเว้น localhost นี่คือเหตุผลทั้งหมดที่การติดตั้งนี้ต้องมี hostname และ certificate ให้ตั้งค่า origin ก่อนการเริ่มต้นครั้งแรก เนื่องจากระบบจะอ่านค่านี้ขณะเริ่มต้น หลังจากแก้ไข .env หรือ compose.yaml แล้ว ให้เรียกใช้ docker compose up -d อีกครั้งเพื่อใช้การตั้งค่าeriwa

เชื่อมต่อ provider รายแรกผ่าน OAuth

สร้าง OAuth app ที่ provider ก่อน สำหรับ GitHub ให้ไปที่ Settings จากนั้น Developer settings, OAuth Apps และ New OAuth App ตามลำดับ ตั้งค่า authorization callback URL เป็น https://connect.example.com/oauth/callback เก็บ client ID และ client secret ไว้

ทุกการเรียก /api จะส่ง admin token ไปด้วย ดังนั้นให้ export token นี้ครั้งเดียวสำหรับ shell session

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

รายการดังกล่าวแสดง redirect URI ที่ runtime คาดว่าจะใช้สำหรับแต่ละ provider จึงเป็นวิธีตรวจสอบที่รวดเร็วที่สุดว่า origin ของคุณมีผลแล้ว หากยังแสดงเป็น localhost แสดงว่า container กำลังทำงานด้วยค่าเดิม และ OAuth flow จะล้มเหลวในขั้นตอนสุดท้าย

จัดเก็บ client credentials แล้วเริ่ม authorization

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

การเรียกครั้งที่สองจะแสดง authorizationUrl ให้เปิดในเบราว์เซอร์ อนุมัติ scopes แล้ว provider จะส่งเบราว์เซอร์กลับไปยัง /oauth/callback จากนั้น runtime จะแลกเปลี่ยน code และจัดเก็บ credential เว็บคอนโซลที่ origin ของคุณจะแนะนำขั้นตอนเดียวกันผ่านฟอร์ม โดยใช้ admin token เดียวกัน Provider ที่ใช้ plain API key จะข้ามขั้นตอนทั้งหมดนี้: PUT /api/connections/<service> พร้อม {"authType":"api_key","values":{"apiKey":"..."}} จะจัดเก็บ key โดยตรง

กำหนดโทเค็นรันไทม์ให้แต่ละเอเจนต์ ห้ามใช้ข้อมูลรับรอง

เอเจนต์จะยืนยันตัวตนกับเกตเวย์ด้วยโทเค็นรันไทม์ ซึ่ง admin API เป็นผู้ออกให้

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

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

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

การตอบกลับที่ทำงานปกติจะเป็น envelope ซึ่งฟิลด์ success มีค่าเป็น true และมี payload ของผู้ให้บริการอยู่ภายใต้ data ไม่มี GitHub token อยู่ในข้อมูลตอบกลับนั้น สำหรับ MCP client ให้ชี้ไปที่ https://connect.example.com/mcp พร้อม bearer header เดิม จากนั้นเกตเวย์จะแสดงเครื่องมือสำหรับการค้นพบ เช่น search_actions และ execute_action แทนการมีเครื่องมือแยกตามแต่ละ API ซึ่งช่วยให้รายการเครื่องมือของเอเจนต์มีขนาดเล็ก การเรียกใช้ MCP servers บน VPS อธิบายส่วนของ client ในการเชื่อมต่อนี้

เรียกใช้การตรวจสอบอีกครั้งก่อนถือว่าการตั้งค่าเสร็จสมบูรณ์ ให้เรียก action เดิมซ้ำโดยลบ header authorization ออก quickstart ของโครงการเรียกใช้ /v1 โดยไม่มี bearer ดังนั้นการติดตั้งที่ไม่ได้กำหนดค่า runtime auth จะดำเนินการแทนผู้ใดก็ตามที่เข้าถึง port ได้ หากการเรียกโดยไม่ยืนยันตัวตนสำเร็จ คุณมีทางแก้ 2 วิธี ได้แก่ กำหนดค่า runtime tokens และยืนยันว่าการเรียกแบบไม่ระบุตัวตนล้มเหลวในขณะนี้ หรือจำกัด /api, /v1 และ /mcp ที่ reverse proxy ให้รับเฉพาะ address ที่เอเจนต์ของคุณใช้เชื่อมต่อ มีเพียง /oauth/callback ที่ต้องเปิดให้สาธารณะเข้าถึงได้ เพราะเป็นเส้นทางเดียวที่ browser redirect ของผู้ให้บริการต้องใช้

ลดรายการการดำเนินการให้เหลือเฉพาะที่เอเจนต์ต้องใช้

เกตเวย์ที่มีผู้ให้บริการ 1,000 รายอยู่เบื้องหลัง เป็นขอบเขตการเข้าถึงที่กว้างเกินไปสำหรับ language model การควบคุม 2 รายการช่วยจำกัดขอบเขตนี้ได้

OOMOL_CONNECT_ALLOWED_ACTIONS รับรายการอนุญาตที่คั่นด้วยเครื่องหมายจุลภาค และรองรับ service.* กับ * ส่วน OOMOL_CONNECT_BLOCKED_ACTIONS คือรายการปฏิเสธ และรายการปฏิเสธมีผลเหนือกว่า การตั้งรายการอนุญาตเป็น github.get_current_user,github.list_issues หมายความว่าการดำเนินการอื่นทั้งหมดจะถูกปฏิเสธ ไม่ว่าเอเจนต์จะร้องขออะไร นี่คือความแตกต่างระหว่างความผิดพลาดกับเหตุการณ์ด้านความปลอดภัย โทเค็นรันไทม์มีกฎการดำเนินการของตนเองเพิ่มเติมจากกฎส่วนกลาง และรายการ allowedProxies ของโทเค็นจะเริ่มต้นเป็นค่าว่าง ดังนั้น POST /v1/proxy/:service จะถูกปฏิเสธจนกว่าคุณจะอนุญาต การเชื่อมต่อปลายทางนั้นจะส่งต่อคำขอดิบไปยังผู้ให้บริการพร้อมแนบข้อมูลรับรองของคุณ ดังนั้นควรปล่อยให้ว่าง เว้นแต่เอเจนต์ใดเอเจนต์หนึ่งจำเป็นต้องใช้โดยเฉพาะ

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK มีค่าเริ่มต้นเป็น false ซึ่งป้องกันไม่ให้การเชื่อมต่อผู้ให้บริการที่โฮสต์เองชี้ไปยังที่อยู่ส่วนตัว เช่น บริการข้อมูลเมทาดาทาของ cloud ที่ 169.254.169.254 หรือฐานข้อมูลของคุณในเครือข่ายเดียวกัน ให้ปิดตัวเลือกนี้ไว้ เปิดใช้เฉพาะกับผู้ให้บริการที่คุณโฮสต์เองเท่านั้น

สำรองข้อมูลเซิร์ฟเวอร์ที่เก็บโทเค็นทั้งหมด

มี 2 สิ่งที่สำคัญ และแต่ละสิ่งจะไม่มีประโยชน์หากขาดอีกสิ่งหนึ่ง ฐานข้อมูลที่ /app/data/connect.sqlite ภายในโวลุ่ม connector-data เก็บข้อมูลรับรองที่ถูกผนึกไว้ คีย์เข้ารหัสใน .env ใช้เปิดผนึกข้อมูลเหล่านั้น การสำรองข้อมูลโวลุ่มโดยไม่มีคีย์จะกู้คืนอะไรไม่ได้ และการสำรองคีย์โดยไม่มีโวลุ่มก็จะกู้คืนอะไรไม่ได้เช่นกัน ดังนั้นให้เก็บคีย์ไว้ใน password manager และรวมโวลุ่มไว้ในรอบการสำรองข้อมูลตามปกติ

หยุด container ขณะคัดลอกไฟล์ SQLite เนื่องจากสำเนาที่สร้างระหว่างการเขียนข้อมูลอาจกู้คืนเป็นฐานข้อมูลที่เสียหายได้

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

ชื่อโวลุ่มคือไดเรกทอรีโครงการของคุณต่อด้วย _connector-data จึงต้องใช้คำสั่งแรกเพื่อดูชื่อ จากนั้นวางชื่อจริงลงในคำสั่งที่สาม ส่งไฟล์ archive ออกจาก VPS ด้วย การสำรองข้อมูล restic จาก VPS ซึ่งจะเข้ารหัสไฟล์ก่อนส่งออกไป เนื่องจาก archive นี้เป็นที่เก็บข้อมูลรับรอง

runtime จะเก็บการทำงานล่าสุดของ agent เป็นระเบียนตรวจสอบ โดยค่าเริ่มต้นคือ 5,000 รายการ เพื่อให้ console ระบุได้ว่า agent ใดทำอะไรและเมื่อใด อ่าน log นี้เป็นสิ่งแรกเมื่อ agent ทำงานผิดปกติ นอกจากนี้ให้ชี้ หน้าสถานะ Uptime Kuma ไปยัง https://connect.example.com/health ด้วย เมื่อ gateway หยุดตอบสนอง agent จะล้มเหลวในลักษณะที่ทำให้วิเคราะห์ได้ยาก และการทราบว่า gateway หยุดทำงานจะช่วยประหยัดเวลาในการอ่านผลลัพธ์ของ agent ได้ 1 ชั่วโมง

สิ่งที่ทำงานผิดพลาด และข้อความที่จะแสดง

redirect_uri_mismatch ที่ผู้ให้บริการ ต้นทางและ URL callback ที่ลงทะเบียนไว้ไม่ตรงกัน ให้เปรียบเทียบสตริงที่ตรงกันทุกอักขระจาก /api/oauth/configs กับการตั้งค่าแอปของผู้ให้บริการ รวมถึงเปรียบเทียบ https กับ http และตรวจสอบเครื่องหมายทับท้ายด้วย

ทุกการเรียก /api ส่งคืน 401 ส่วนหัวโทเค็นผู้ดูแลระบบหายไปหรือสะกดไม่ถูกต้อง ส่วนหัวคือ Authorization: Bearer <token> และคอนโซลเว็บต้องใช้โทเค็นเดียวกัน

คอนเทนเนอร์ทำงาน แต่ข้อมูลรับรองอยู่ในรูปแบบข้อความธรรมดา เหตุการณ์นี้เกิดขึ้นเมื่อ OOMOL_CONNECT_ENCRYPTION_KEY ไม่ถูกส่งไปยังคอนเทนเนอร์ เนื่องจาก runtime จัดเก็บระเบียนข้อมูลรับรองโดยไม่เข้ารหัส แทนที่จะปฏิเสธการเริ่มทำงาน ให้พิสูจน์บนการติดตั้งของคุณเอง โดยเชื่อมต่อผู้ให้บริการด้วย API key ที่คุณจำแนกได้ จากนั้นค้นหา API key ดังกล่าวในฐานข้อมูล

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

ค่าที่มากกว่า 0 หมายความว่า key ยังไม่มีผล ดังนั้นตรวจสอบว่า .env อยู่ในไดเรกทอรีเดียวกับ compose.yaml และ docker compose config แสดงค่าดังกล่าว เมื่อกำหนด key แล้ว การค้นหาเดิมจะส่งคืนค่า 0 เนื่องจากระเบียนถูกปิดผนึกด้วย AES-256-GCM (มาตรฐานการเข้ารหัสขั้นสูง, key ขนาด 256 บิต, โหมด Galois/counter)

ไม่มีข้อมูลใดถอดรหัสได้หลังการกู้คืน key สำหรับการเข้ารหัสเปลี่ยนแปลงหรือสูญหาย ระบบจะไม่เขียน key ไว้ใกล้กับข้อมูลโดยการออกแบบ ดังนั้นจึงไม่มีวิธีกู้คืน และการส่งคำขอรับความช่วยเหลือก็ไม่ช่วยแก้ปัญหา ให้เชื่อมต่อผู้ให้บริการทุกรายอีกครั้ง ระบบรองรับการหมุนเวียน key ผ่านตัวแปร key แยกต่างหากและคำสั่งข้อมูลใน runtime ดังนั้นให้อ่านบันทึกประจำรุ่นปัจจุบันก่อนหมุนเวียน key ใด ๆ

เอเจนต์แสดงข้อผิดพลาดที่ระบุชื่อ action ซึ่งมีอยู่ในแค็ตตาล็อก การค้นหาและการดำเนินการเป็นคนละขั้นตอนกัน action อาจปรากฏใน search_actions แต่ยังถูกปฏิเสธโดย OOMOL_CONNECT_ALLOWED_ACTIONS, denylist หรือกฎของโทเค็น runtime นั้นเอง

การอัปเกรด สำรองข้อมูล volume แก้ไข image tag ให้เป็นรุ่นใหม่ แล้วเรียกใช้ docker compose pull && docker compose up -d ตรวจสอบ docker compose logs -n 50 connector เพื่อหาบรรทัดการย้ายข้อมูล จากนั้นเรียกใช้ health check และ action จริง 1 รายการอีกครั้งก่อนเชื่อถือระบบ การย้อนกลับหมายถึงการใส่ tag เดิมกลับคืน ซึ่งทำงานได้เพราะคุณกำหนด tag ไว้แบบตายตัว

FAQ

จำเป็นต้องมีโดเมนสาธารณะเพื่อโฮสต์ Open Connector ด้วยตนเองหรือไม่

สำหรับผู้ให้บริการที่ใช้ API key ไม่จำเป็น: gateway บน 127.0.0.1 ก็เพียงพอแล้ว แต่ในทางปฏิบัติจำเป็นสำหรับ OAuth ผู้ให้บริการจะเปลี่ยนเส้นทางเบราว์เซอร์ไปยัง callback URL ของคุณ ดังนั้น URL ดังกล่าวต้องเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ และผู้ให้บริการจะปฏิเสธ http:// แบบไม่เข้ารหัสนอก localhost กำหนด OOMOL_CONNECT_ORIGIN เป็นชื่อโฮสต์ https:// ของคุณก่อนเริ่มใช้งานครั้งแรก และลงทะเบียน <origin>/oauth/callback ในแอป OAuth ของผู้ให้บริการ

จะเกิดอะไรขึ้นหากทำคีย์เข้ารหัสของ Open Connector หาย

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

AI agent ของฉันจะเห็น access token ของผู้ให้บริการได้หรือไม่

ไม่เห็นเมื่อเรียกใช้ผ่าน gateway agent จะยืนยันตัวตนด้วย runtime token ที่ขึ้นต้นด้วย oct_ และ gateway จะแทรกข้อมูลประจำตัวของผู้ให้บริการลงในคำขอขาออกบนเซิร์ฟเวอร์ จากนั้นส่งกลับเฉพาะการตอบกลับ มี 2 กรณีที่ทำให้คุณสมบัตินี้ใช้ไม่ได้ ได้แก่ endpoint /v1/proxy/:service ซึ่งส่งต่อคำขอดิบพร้อมแนบข้อมูลประจำตัวของคุณ และกำหนดสิทธิ์เริ่มต้นเป็นค่าว่างด้วยเหตุผลด้านความปลอดภัย อีกกรณีคือการวาง API key ลงใน agent ด้วยตนเอง ซึ่งจะข้าม gateway ทั้งหมด

ควรเปิดให้ gateway เข้าถึงได้จากอินเทอร์เน็ตสาธารณะหรือไม่

มีเพียง /oauth/callback ที่ต้องเข้าถึงได้ เผยแพร่พอร์ตของ container บน 127.0.0.1 เพื่อไม่ให้กฎ NAT ของ Docker เปิดให้เข้าถึงผ่าน firewall ของคุณ และวาง reverse proxy ไว้ด้านหน้า จากนั้นทดสอบการเรียกใช้ action 1 ครั้งโดยไม่มี header authorization หากสำเร็จ ให้จำกัด /api, /v1 และ /mcp ที่ proxy ให้เหลือเฉพาะ address ที่ agent ของคุณใช้ จนกว่าคำขอที่ผ่านการยืนยันตัวตนจะเป็นคำขอประเภทเดียวที่ทำงานได้

Open Connector พร้อมสำหรับใช้งานจริงหรือไม่

ซอฟต์แวร์นี้ใช้สัญญาอนุญาต Apache 2.0 และมีการพัฒนาอย่างรวดเร็ว: repository ปรากฏเมื่อ 29 June 2026 และมีการเผยแพร่ v1.3.3 เมื่อ 30 July 2026 ดังนั้นให้ถือว่าหมายเลขเวอร์ชันทุกหมายเลขในคู่มือนี้เป็นภาพรวม ณ 1 August 2026 เรียกใช้โดยระบุ release tag อย่างตายตัว ห้ามใช้ latest หรือ tip อ่าน release notes ก่อนอัปเกรดแต่ละครั้ง และเก็บสำเนาสำรองของ volume ที่คุณเคยกู้คืนและตรวจสอบแล้ว 1 ครั้ง การออกแบบเหมาะสมสำหรับระบบที่คุณเป็นเจ้าของ และความเสี่ยงอยู่ที่การเปลี่ยนแปลงเวอร์ชัน ไม่ใช่สถาปัตยกรรม