วิธีเข้าใช้งาน DeepSeek Harness Web UI ที่ 127.0.0.1:3080

ความหมายของ dsh web: http://127.0.0.1:3080

เมื่อคุณเริ่มใช้งาน DeepSeek Harness web profile บน VPS ระบบจะแสดงข้อความสองบรรทัดแล้วหยุดรอ:

dsh web: http://127.0.0.1:3080
Ready.

127.0.0.1 คือ loopback address ซึ่งเป็นที่อยู่ที่เครื่องใช้สำหรับสื่อสารกับตัวเอง ซ็อกเก็ตที่ผูกไว้กับ 127.0.0.1 จะยอมรับการเชื่อมต่อจากโพรเซสที่อยู่บนเครื่องเดียวกันเท่านั้น ไม่รับจากที่อื่น ดังนั้นบรรทัดนี้จึงบอกข้อมูลสองอย่างพร้อมกัน คือตำแหน่งที่ Web UI กำลังฟังอยู่ และใครบ้างที่ได้รับอนุญาตให้เข้าถึงได้ ซึ่งก็คือเฉพาะเครื่องที่ dsh กำลังทำงานอยู่เท่านั้น

นี่คือเหตุผลว่าทำไม URL ถึงไม่ทำงานเมื่อคุณนำไปวางในเบราว์เซอร์บนแล็ปท็อปของคุณ เพราะ 127.0.0.1 ของแล็ปท็อปคุณคือตัวแล็ปท็อปเอง แต่ Harness กำลังฟังอยู่ที่ 127.0.0.1 ของ VPS ซึ่งเป็นคนละเครื่องและมี loopback stack แยกจากกัน ไม่ได้มีอะไรเสียหาย คุณเพียงแค่ต้องเชื่อมต่อข้ามเครื่องมาเท่านั้น

README อย่างเป็นทางการระบุค่าเริ่มต้นไว้อย่างชัดเจนว่า: "คำสั่งนี้จะเริ่ม Web UI โดยให้บริการที่ http://127.0.0.1:3080 เป็นค่าเริ่มต้น" ที่อยู่สำหรับ bind มาจาก webserver host plugin ที่ชื่อ @deepseek-ai/dsh-host-webserver ซึ่งคีย์ host ได้รับการระบุไว้ในเอกสารว่า "Listen host; ค่าที่รองรับมีสองค่าคือ loopback และ all-interfaces" คุณจะได้รับค่าเป็น loopback เว้นแต่คุณจะเข้าไปเปลี่ยนมัน หากคุณยังไม่คุ้นเคยกับพอร์ต การทำงานของพอร์ตบน Linux จะอธิบายถึงโมเดล address-plus-port ซึ่งเป็นพื้นฐานของเรื่องทั้งหมดนี้

เหตุใด Web UI จึงผูกไว้กับ localhost เท่านั้น

dsh เป็น agent harness ซึ่งก็คือ โปรแกรมที่ครอบตัวโมเดลไว้: มันเป็นผู้ควบคุมลูป การเรียกใช้เครื่องมือ และสิทธิ์ที่การเรียกเหล่านั้นทำงานภายใต้ แท็บเบราว์เซอร์ทำหน้าที่เป็นแผงควบคุมสำหรับกระบวนการที่รันคำสั่ง shell, อ่านและเขียนไฟล์ในไดเรกทอรี workspace ที่คุณเลือก และใช้ API key ของโมเดลของคุณ ใครก็ตามที่สามารถโหลดหน้านั้นได้สามารถทำทุกอย่างได้ในฐานะผู้ใช้ที่รัน dsh นอกจากนี้ เครือข่ายไม่ใช่ช่องทางเดียวในการเข้าถึงสิทธิ์ดังกล่าว ปลั๊กอินที่คุณติดตั้งจะรันภายในกระบวนการเดียวกันด้วยสิทธิ์เดียวกัน ซึ่งเป็นเหตุผลว่าทำไม การตรวจสอบปลั๊กอิน dsh ก่อนติดตั้ง จึงต้องใช้ความระมัดระวังเช่นเดียวกับการตัดสินใจว่าเซิร์ฟเวอร์ควรฟังพอร์ตใด

ดังนั้นพอร์ต 3080 จึงไม่ใช่แดชบอร์ดแบบอ่านอย่างเดียว การโหลดหน้านั้นจะทำให้สามารถรันคำสั่งบนเซิร์ฟเวอร์ได้

เมื่อเปิด Web UI คุณจะเข้าสู่รายการเซสชันทันที โดยไม่มีหน้าจอให้ล็อกอิน เนื่องจากรุ่น developer preview ยังไม่มีระบบบัญชีผู้ใช้และการตรวจสอบสิทธิ์จากระยะไกล การผูกไว้กับ loopback จึงมีความสอดคล้องกัน: ระบบปฏิบัติการทำหน้าที่เป็นตัวควบคุมการเข้าถึง และมีเพียงกระบวนการในเครื่องเท่านั้นที่ผ่านเข้ามาได้ หากคุณผูกเซิร์ฟเวอร์เดียวกันนี้เข้ากับ 0.0.0.0 บน VPS ที่มี public IP หน้าเว็บเดียวกันนั้นจะตอบสนองต่ออินเทอร์เน็ตทั้งหมดโดยไม่มีอะไรป้องกัน สแกนเนอร์อัตโนมัติจะกวาดหาพอร์ตที่ไม่ธรรมดาอย่างต่อเนื่อง ดังนั้นให้ถือว่าพอร์ต 3080 ที่เปิดเผยสู่สาธารณะนั้นถูกค้นพบแล้ว

ห้ามเปิดพอร์ต 3080 ในไฟร์วอลล์ของคุณ และห้ามตั้งค่าเว็บเซิร์ฟเวอร์ host เป็น 0.0.0.0 บน VPS สาธารณะ การทำเช่นนั้นจะมอบสิทธิ์การรันคำสั่งบนเซิร์ฟเวอร์ของคุณให้กับใครก็ตามที่เชื่อมต่อเข้ามาเป็นคนแรก

เหตุผลเดียวกันนี้ใช้กับ agent runtime ทุกตัวที่คุณติดตั้งบนเซิร์ฟเวอร์ ซึ่งเป็นเหตุผลว่าทำไม การรัน coding agent บน VPS อย่างปลอดภัย จึงเริ่มต้นจากกฎเดียวกัน: พอร์ตควบคุมของ agent ต้องเป็นส่วนตัว และคุณควรเข้าถึงผ่านช่องทางที่คุณเชื่อถือเท่านั้น

ฉันจะเปิด Web UI ของ dsh จากแล็ปท็อปได้อย่างไร

มีวิธีที่เหมาะสมอยู่ 3 วิธี และทุกวิธีจะยังคงผูก harness ไว้กับ loopback ตามเดิม

• การทำ SSH tunnel: ไม่มีการเปิดพอร์ตใหม่บน public interface และคุณมี credential อยู่แล้ว นี่คือวิธีที่ควรเลือกใช้
• การใช้ private overlay network: เพื่อให้สามารถเข้าถึง UI ได้จากอุปกรณ์ของคุณเองโดยที่ผู้อื่นไม่สามารถมองเห็นได้
• การใช้ reverse proxy: เพื่อทำ TLS (transport layer security) termination และบังคับให้ใส่รหัสผ่านก่อนที่จะส่งต่อคำขอใดๆ

ความแตกต่างของแต่ละวิธีคือวิธีการนำเบราว์เซอร์ของคุณไปเชื่อมต่อกับ loopback โดยไม่ควรมีวิธีใดที่ต้องย้ายการทำงานของ harness ออกจาก loopback

เข้าถึงด้วย SSH tunnel

ให้รันคำสั่งนี้บนแล็ปท็อปของคุณ ไม่ใช่บน VPS:

ssh -N -L 3080:127.0.0.1:3080 you@your-vps

ปล่อยให้คำสั่งทำงานทิ้งไว้ จากนั้นเปิด http://127.0.0.1:3080 ในเบราว์เซอร์บนเครื่องของคุณ หน้า Web UI จะโหลดขึ้นมา

อาร์กิวเมนต์ -L ประกอบด้วยสามฟิลด์ที่คั่นด้วยเครื่องหมายโคลอน ฟิลด์แรกคือพอร์ตที่จะเปิดบนแล็ปท็อปของคุณ ส่วนฟิลด์ที่สองและสามคือที่อยู่และพอร์ตที่จะส่งต่อการเชื่อมต่อแต่ละรายการไป รายละเอียดที่สำคัญคือ 127.0.0.1 ในฟิลด์กลางจะถูกแก้ไขโดย SSH server บน VPS หลังจากที่ทราฟฟิกของคุณไปถึงที่นั่นแล้ว ซึ่งหมายถึง loopback ของ VPS ไม่ใช่ของคุณ นี่คือที่อยู่ที่ dsh แสดงไว้ ซึ่งเป็นเหตุผลว่าทำไม tunnel ถึงใช้งานได้ในขณะที่การเชื่อมต่อผ่านเบราว์เซอร์โดยตรงใช้งานไม่ได้

-N บอกให้ SSH ไม่ต้องรันคำสั่งบนรีโมท คุณจึงได้ตัวส่งต่อโดยไม่มีเชลล์ สำหรับ tunnel ที่ทำงานเบื้องหลังและแจ้งเตือนเมื่อเกิดข้อผิดพลาดแทนที่จะเงียบหายไป:

ssh -N -f -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -L 3080:127.0.0.1:3080 you@your-vps

-f จะส่งกระบวนการไปทำงานเบื้องหลังหลังจากยืนยันตัวตนแล้ว ExitOnForwardFailure=yes มีความสำคัญมากกว่าที่เห็น: หากไม่มีอาร์กิวเมนต์นี้ SSH จะเชื่อมต่อสำเร็จแม้ว่าจะตั้งค่าการส่งต่อไม่ได้ ทำให้คุณได้เซสชันที่ใช้งานได้แต่ tunnel กลับใช้งานไม่ได้โดยไม่มีการแจ้งเตือน ServerAliveInterval=30 จะส่ง keepalive ทุก 30 วินาที เพื่อให้ tunnel ที่ไม่ได้ใช้งานยังคงอยู่ได้แม้จะเจอกับ NAT (network address translation) timeout บนเราเตอร์ของร้านกาแฟหรือโรงแรม

สิ่งที่คุณควรเห็น

บน VPS ให้ยืนยันว่ามีอะไรกำลังฟังพอร์ตอยู่จริง:

ss -ltnp | grep 3080

ผลลัพธ์ที่ปกติจะระบุที่อยู่ loopback:

LISTEN 0  511  127.0.0.1:3080  0.0.0.0:*  users:(("node",pid=1042,fd=21))

หากคอลัมน์ที่อยู่ภายใน (local address) แสดงเป็น 0.0.0.0:3080 ให้หยุดบริการและแก้ไขการ bind ก่อนที่จะทำสิ่งอื่น หาก ss แสดงซ็อกเก็ตแต่ปล่อยให้ฟิลด์ users: ว่างเปล่า ให้รันด้วย sudo เนื่องจากชื่อกระบวนการสำหรับซ็อกเก็ตที่เป็นของผู้ใช้อื่นจะถูกซ่อนไว้หากไม่ใช้สิทธิ์ดังกล่าว

เมื่อ tunnel ปฏิเสธที่จะเริ่มทำงาน

SSH จะพิมพ์ข้อความนี้และออกจากโปรแกรม:

bind [127.0.0.1]:3080: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 3080

ปัญหานี้เกี่ยวกับแล็ปท็อปของคุณ ไม่ใช่เซิร์ฟเวอร์ มีบางอย่างในเครื่องที่จองพอร์ต 3080 ไว้แล้ว ซึ่งมักจะเป็น tunnel ก่อนหน้าที่คุณลืมปิด ให้เลือกพอร์ตภายในที่ว่างแทน:

ssh -N -L 3081:127.0.0.1:3080 you@your-vps

เฉพาะฟิลด์แรกเท่านั้นที่เปลี่ยนไป ดังนั้นตอนนี้คุณจึงเข้าถึง http://127.0.0.1:3081 ในขณะที่ harness ยังคงฟังพอร์ต 3080 อยู่ ตัวเลขทั้งสองไม่จำเป็นต้องตรงกัน

หาก tunnel เริ่มทำงานได้แต่เบราว์เซอร์รายงานว่าการเชื่อมต่อถูกปฏิเสธหรือได้รับคำตอบที่ว่างเปล่า แสดงว่าทราฟฟิกส่งไปถึง VPS แล้วแต่ไม่พบปลายทาง อาจเป็นเพราะ dsh ออกจากโปรแกรมไปแล้ว หรือมีการ bind พอร์ตอื่น ให้ตรวจสอบด้วย ss -ltnp | grep 3080 บนเซิร์ฟเวอร์

อีกสิ่งหนึ่งที่มักเป็นปัญหาคือ npx @deepseek-ai/dsh web ที่รันอยู่เบื้องหน้าจะหยุดทำงานเมื่อเชลล์ปิดลง ดังนั้น harness จะหยุดทันทีที่คุณออกจากระบบ ให้เริ่มทำงานภายใน tmux หรือภายใต้ systemd user service ซึ่งเป็นปัญหาเดียวกันกับที่แก้ไขไว้ใน การรักษาให้ coding agent ทำงานบน VPS ในระหว่างที่คุณกำลังจัดการฝั่ง SSH การ เพิ่มความปลอดภัยให้กับ SSH บน VPS ของคุณ เป็นสิ่งที่ควรทำก่อน เพราะ tunnel จะทำให้การล็อกอิน SSH ของคุณเป็นประตูเดียวที่เข้าถึง agent ได้

การเข้าถึงผ่านเครือข่าย overlay ส่วนตัว

เครือข่าย overlay ช่วยให้ VPS และแล็ปท็อปของคุณมีที่อยู่บนเครือข่ายส่วนตัวที่มีเพียงอุปกรณ์ของคุณเท่านั้นที่เข้าร่วมได้ Tailscale เป็นตัวเลือกที่นิยมใช้ และคำสั่ง serve ของมันก็เหมาะกับกรณีนี้อย่างยิ่ง โดย tailscaled จะทำงานบน VPS และเชื่อมต่อเข้ากับ localhost:3080 ของตัวมันเอง ทำให้ harness ยังคงทำงานอยู่บน loopback และคุณไม่จำเป็นต้องเปลี่ยนแปลงการตั้งค่าใดๆ ของ dsh เลย

tailscale serve --bg localhost:3080
tailscale serve status

จากนั้นคุณจะสามารถเข้าถึง UI ได้ผ่านชื่อเครื่องของคุณภายใน tailnet ด้วยโปรโตคอล HTTPS โดยไม่ต้องเปิดพอร์ตใดๆ บนอินเทอร์เฟซสาธารณะ วิธีนี้จำเป็นต้องเปิดใช้งานใบรับรอง HTTPS สำหรับ tailnet ของคุณ มิฉะนั้น serve จะไม่มีใบรับรองสำหรับแสดงผล หากต้องการยกเลิกการใช้งาน ให้ทำซ้ำคำสั่งเดิมด้วย off:

tailscale serve --https=443 off

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

เข้าถึงผ่าน reverse proxy ที่มีการตรวจสอบรหัสผ่าน

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

ตัว harness จะทำงานบน 127.0.0.1:3080 โดยมี nginx ทำงานอยู่บนเครื่องเดียวกัน จึงสามารถเข้าถึง loopback ได้ และ nginx จะคอยฟังที่พอร์ต 443 พร้อมกับใช้ certificate และไฟล์รหัสผ่าน

server {
    listen 443 ssl;
    server_name dsh.example.com;

    ssl_certificate     /etc/letsencrypt/live/dsh.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dsh.example.com/privkey.pem;

    auth_basic           "dsh";
    auth_basic_user_file /etc/nginx/dsh.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:3080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

สร้างไฟล์รหัสผ่านและโหลดการตั้งค่าใหม่:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/dsh.htpasswd you
sudo nginx -t && sudo systemctl reload nginx

nginx -t ควรแสดงผล syntax is ok ตามด้วย test is successful หากการโหลดใหม่ล้มเหลวเนื่องจากไฟล์มีปัญหา ระบบจะยังคงใช้การตั้งค่าเดิมที่ทำงานอยู่ ดังนั้นให้อ่านข้อความแสดงข้อผิดพลาดแทนการรีสตาร์ทแบบสุ่มสี่สุ่มห้า

บรรทัด proxy สามบรรทัดนั้นไม่ใช่แค่การตกแต่ง แต่ header Upgrade และ Connection ช่วยให้การทำ WebSocket handshake ผ่านไปได้ หากไม่มีบรรทัดเหล่านี้ หน้าเว็บจะโหลดขึ้นมาแต่จะไม่แสดงข้อมูลอัปเดต ส่วน proxy_read_timeout 3600s จะเข้ามาแทนที่ค่าเริ่มต้น 60 วินาที ซึ่งหากไม่เปลี่ยน ค่าเดิมจะตัดการทำงานของ agent ที่ใช้เวลานานกลางคันและทำให้ UI ดูค้างไป ส่วน proxy_buffering off จะส่งผลลัพธ์จากโมเดลไปยังเบราว์เซอร์ทันทีที่ได้รับ แทนที่จะรอจนกว่าการตอบกลับจะเสร็จสิ้น คำอธิบายการตั้งค่า nginx reverse proxy ทีละบรรทัด จะอธิบายส่วนที่เหลือ และ การเลือกใช้งานระหว่าง nginx, Caddy และ Traefik จะครอบคลุมถึงการทำสิ่งเดียวกันด้วยการจัดการ certificate อัตโนมัติ

ปิดพอร์ต 3080 ที่ firewall ไว้เสมอไม่ว่าคุณจะเลือกใช้ proxy แบบใด เพื่อให้เส้นทางเดียวที่จะเข้าถึงระบบได้คือผ่านช่องทางที่มีการยืนยันตัวตนเท่านั้น พื้นฐานการใช้งาน ufw firewall จะครอบคลุมถึงการตั้งค่ากฎต่างๆ การใช้ basic authentication ผ่าน TLS เป็นเพียงมาตรฐานขั้นต่ำ ไม่ใช่โมเดลความปลอดภัยที่สมบูรณ์แบบ: ใครก็ตามที่ถือรหัสผ่านนั้นย่อมถือสิทธิ์ในการเข้าถึง shell บนเซิร์ฟเวอร์ของคุณได้ หากทำได้ควรเลือกใช้ tunnel จะปลอดภัยกว่า

ฉันจะเปลี่ยนพอร์ตที่ dsh web ใช้รับการเชื่อมต่อได้อย่างไร

--port เป็นส่วนของเว็บแอปพลิเคชัน ไม่ใช่ของตัว launcher เอกสารประกอบ CLI ได้ให้ตัวอย่างไว้โดยตรงดังนี้:

dsh --profile web --port 8080

dsh web เป็นนามแฝงของ --profile web ดังนั้น dsh web --port 8080 จึงเป็นคำสั่งเดียวกัน ตัว launcher จะประมวลผลเฉพาะ flag ของตัวมันเองเท่านั้น แล้วส่งต่อทุกอย่างที่เหลือหลังจากนั้นไปยังโปรไฟล์ที่ถูกเรียกใช้งาน ดังนั้น flag ของ launcher ต้องอยู่ข้างหน้าเสมอ และ token แรกที่ launcher ไม่รู้จักจะถือเป็นจุดเริ่มต้นของอาร์กิวเมนต์สำหรับแอปพลิเคชัน ให้วาง --port ไว้หลังโปรไฟล์เสมอ ห้ามวางไว้ข้างหน้า

ให้อ่าน URL ที่คำสั่งแสดงผลออกมาแทนการคาดเดา เพราะบรรทัดนั้นจะรายงานที่อยู่ที่เซิร์ฟเวอร์ผูกไว้จริง จากนั้นให้ปรับปรุงฟิลด์สุดท้ายของ tunnel ของคุณให้ตรงกัน:

ssh -N -L 3080:127.0.0.1:8080 you@your-vps

สำหรับการเปลี่ยนแปลงแบบถาวร พอร์ตจะถูกกำหนดไว้ในการตั้งค่าโปรไฟล์แทนที่จะกำหนดผ่านบรรทัดคำสั่ง โปรไฟล์ web และ headless จะถูกสร้างขึ้นโดยอัตโนมัติในการใช้งานครั้งแรกจากเทมเพลตที่มาพร้อมกับโปรแกรม ภายใต้ไดเรกทอรี ~/.dsh ไดเรกทอรีเดียวกันนี้ยังเป็นที่เก็บ API key และการตั้งค่า model endpoint ของคุณ ดังนั้น การตั้งค่า dsh keys, models และ endpoints จึงเป็นเนื้อหาที่ควรอ่านควบคู่กันไปเมื่อคุณต้องแก้ไขไฟล์เหล่านี้อยู่แล้ว หากต้องการดูว่าการตั้งค่าใดมีผลจริงหลังจากรวมเลเยอร์ทั้งหมดแล้ว ให้ใช้คำสั่ง:

dsh --dump-config

ปลั๊กอินเว็บเซิร์ฟเวอร์เปิดเผย key ออกมาเพียงสองรายการเท่านั้น คือ host และ port การตั้งค่า port เป็น 0 คือการร้องขอพอร์ตว่างจากระบบปฏิบัติการ ซึ่งมีเอกสารระบุไว้ว่า "การระบุค่าศูนย์เป็นการร้องขอพอร์ตที่ระบบปฏิบัติการจัดสรรให้" วิธีนี้รับประกันว่าคุณจะไม่พบปัญหาพอร์ตชนกัน แต่ไม่เหมาะกับการทำ tunnel เพราะหมายเลขพอร์ตจะเปลี่ยนไปทุกครั้งที่รีสตาร์ทโปรแกรม

เหตุใด dsh จึงล้มเหลวด้วยข้อความ address already in use?

เนื่องจากมีโพรเซสอื่นใช้งานแอดเดรสและพอร์ตนั้นอยู่แล้ว เคอร์เนลจึงปฏิเสธการ bind ครั้งที่สอง Node จะรายงานข้อผิดพลาดในลักษณะนี้:

Error: listen EADDRINUSE: address already in use 127.0.0.1:3080

ให้ค้นหาโพรเซสที่ใช้งานอยู่ก่อนที่จะดำเนินการแก้ไขใดๆ:

sudo ss -ltnp | grep 3080

ฟิลด์ users:(("node",pid=1042,fd=21)) จะระบุชื่อโพรเซสและ PID ของโพรเซสนั้น คำตอบที่พบบ่อยคือมี dsh ตัวก่อนหน้าที่คุณคิดว่าหยุดทำงานไปแล้ว แต่จริงๆ ยังคงทำงานอยู่ในหน้าต่าง tmux ที่ถูกแยกออกมา ให้หยุดโพรเซสนั้นด้วย kill 1042 หรือเริ่มอินสแตนซ์ใหม่บนพอร์ตอื่น โปรดทราบว่า 127.0.0.1:3080 และ 0.0.0.0:3080 จะเกิดการชนกันเองเสมอ เนื่องจากการ bind ทุกอินเทอร์เฟซนั้นครอบคลุมถึง loopback อยู่แล้ว

ตรึงเวอร์ชันไว้ เนื่องจากเป็นรุ่น developer preview

README ระบุไว้อย่างชัดเจนว่า DeepSeek Harness ยังอยู่ในสถานะ developer preview และมีการพัฒนาอย่างรวดเร็ว ซึ่งจะมีการเปลี่ยนแปลงที่ส่งผลต่อความเข้ากันได้ (compatibility-breaking changes) หากความเร็วในการพัฒนานี้เป็นเหตุผลที่คุณลังเล การเปรียบเทียบ dsh กับ Claude Code และ Omnigent จะช่วยวิเคราะห์เปรียบเทียบกับเครื่องมืออื่นที่อยู่ในจุดต่างกันบนเส้นทางการพัฒนาเดียวกัน

npx @deepseek-ai/dsh web จะดึงเวอร์ชันล่าสุดที่เผยแพร่มาใช้งานทุกครั้งที่คุณรันคำสั่ง เซิร์ฟเวอร์ที่คุณไม่ได้เข้าไปจัดการเป็นเวลาหนึ่งสัปดาห์อาจเริ่มการทำงานด้วย CLI เวอร์ชันที่ต่างออกไปในการเปิดใช้งานครั้งถัดไป พร้อมด้วย flag ที่เปลี่ยนไป คุณควรตรึงเวอร์ชันไว้เพื่อไม่ให้การรีสตาร์ทกลายเป็นการอัปเกรดโดยไม่ตั้งใจ:

npx @deepseek-ai/dsh@0.1.0-rc.7 web

ณ เดือนสิงหาคม 2026 แพ็กเกจที่เผยแพร่อยู่คือเวอร์ชัน 0.1.0-rc.7 ให้ตรวจสอบว่าการรัน npx แบบปกติจะดึงเวอร์ชันใดมาก่อนที่คุณจะยอมรับ:

npm view @deepseek-ai/dsh version

หากการตรึงเวอร์ชันไม่สามารถติดตั้งได้ หรือ npx ยังคงรัน build เก่าหลังจากที่คุณตรึงเวอร์ชันใหม่แล้ว ข้อผิดพลาดในการติดตั้งและเวอร์ชันที่อาจเกิดขึ้น จะอธิบายวิธีล้าง npx cache และการตรวจสอบว่า Node ของคุณใช้ npm ตัวใด

Flag ต่างๆ อาจมีการย้ายตำแหน่งระหว่างตัวเรียกใช้งาน (launcher) และเว็บแอปพลิเคชันในแต่ละรุ่น preview หาก --port เริ่มทำงานไม่ตรงกับที่คู่มือนี้อธิบายไว้ ให้เรียกดูรายการ flag จากตัวแอปพลิเคชันโดยตรงแทนการคาดเดา:

dsh --profile web --help

สำหรับการติดตั้ง การตั้งค่า workspace และการใส่ model key โปรดดู การติดตั้ง DeepSeek Harness บน VPS สำหรับขั้นตอนการเข้าถึงแบบย่อ การเข้าถึง dsh Web UI บน VPS จะอธิบายเฉพาะเรื่องการทำ tunnel โดยไม่ลงรายละเอียดเชิงลึกเกี่ยวกับกลไกการทำงาน

FAQ

ทำไมฉันถึงเปิด http://127.0.0.1:3080 ในเบราว์เซอร์บนแล็ปท็อปไม่ได้?

เพราะ 127.0.0.1 หมายถึงเครื่องที่คุณกำลังใช้งานอยู่ Web UI ของ DeepSeek Harness ถูกผูกไว้กับ loopback address ของ VPS ดังนั้นจะมีเพียงกระบวนการที่ทำงานบน VPS เท่านั้นที่เชื่อมต่อได้ แล็ปท็อปของคุณมี loopback แยกต่างหาก และไม่มีบริการใดรอรับการเชื่อมต่อที่พอร์ต 3080 บนเครื่องนั้น ให้ทำ port forwarding ผ่าน SSH ด้วยคำสั่ง ssh -N -L 3080:127.0.0.1:3080 you@your-vps จากนั้นจึงโหลด http://127.0.0.1:3080 ในเครื่องของคุณ ค่าในส่วนกลางของอาร์กิวเมนต์ -L จะถูกแก้ไข (resolve) ที่ฝั่งเซิร์ฟเวอร์ ซึ่งทำให้มันชี้ไปยังตัว harness ได้อย่างถูกต้อง

การผูก dsh Web UI ไว้ที่ 0.0.0.0 บน VPS สาธารณะปลอดภัยหรือไม่?

ไม่ปลอดภัย Web UI เป็นส่วนควบคุมสำหรับเอเจนต์ที่รันคำสั่ง shell และแก้ไขไฟล์ในฐานะผู้ใช้ที่รัน dsh และในเวอร์ชัน developer preview นี้ยังไม่มีหน้าจอสำหรับล็อกอิน การผูกไว้กับทุกอินเทอร์เฟซบน IP สาธารณะหมายความว่าใครก็ตามที่เข้าถึงพอร์ต 3080 ได้จะสามารถรันคำสั่งบนเซิร์ฟเวอร์ของคุณได้ ให้ผูกไว้ที่ 127.0.0.1 เท่านั้น ปิดพอร์ต 3080 ที่ไฟร์วอลล์ และใช้ SSH tunnel, เครือข่ายส่วนตัว (overlay network) หรือ reverse proxy ที่มีการป้องกันด้วยรหัสผ่านแทน

ฉันจะให้ dsh Web UI ทำงานต่อไปได้อย่างไรหลังจากปิดเซสชัน SSH?

การรัน npx @deepseek-ai/dsh web ไว้ที่ foreground จะทำให้มันเป็น child process ของ login shell ของคุณ ซึ่งจะถูกปิดลงเมื่อ shell นั้นสิ้นสุดการทำงาน ให้เริ่มการทำงานภายในเซสชัน tmux แล้ว detach ออกด้วย Ctrl-b d หรือรันเป็น systemd user service โดยเปิดใช้งาน lingering ไว้ ตัว tunnel และตัว harness นั้นเป็นอิสระต่อกัน คุณสามารถตัดและสร้าง SSH tunnel ใหม่ได้บ่อยเท่าที่ต้องการโดยไม่กระทบต่อ harness ที่กำลังทำงานอยู่ ตราบใดที่ harness นั้นมี parent process ที่ยังคงทำงานอยู่หลังจากที่คุณออกจากระบบไปแล้ว

ทำไม dsh Web UI ถึงค้างระหว่างการรันเอเจนต์ที่ใช้เวลานานเมื่ออยู่หลัง nginx?

เพราะค่าเริ่มต้นของ proxy_read_timeout ใน nginx คือ 60 วินาที ทำให้มันปิดการเชื่อมต่อที่ไม่มีการส่งข้อมูลเป็นเวลาหนึ่งนาที ซึ่งขั้นตอนการทำงานของเอเจนต์ที่ใช้เวลานานมักจะเกิดเหตุการณ์นี้ได้ง่าย ให้ตั้งค่า proxy_read_timeout 3600s; ในบล็อก location เพิ่มคำสั่ง proxy_buffering off; เพื่อให้ output ส่งไปยังเบราว์เซอร์ทันทีที่ได้รับ และส่งผ่าน header Upgrade และ Connection ด้วย proxy_http_version 1.1; เพื่อให้การทำ WebSocket handshake สำเร็จ หากไม่มี header เหล่านี้ หน้าเว็บจะโหลดขึ้นมาแต่จะไม่ได้รับข้อมูลอัปเดตใดๆ เลย