ยืนยันก่อนว่าเครือข่ายขาออกของคุณเชื่อถือได้
Claude Code ใช้งานได้ผ่านอินเทอร์เน็ตบ้าน เครือข่ายองค์กร proxy ที่ควบคุมได้ หรือเกตเวย์ขององค์กรที่เป็นไปตามข้อกำหนด สำหรับบัญชีทั่วไป เครือข่ายที่เสถียรในระยะยาวและมีเจ้าของชัดเจนมักดีกว่า VPN สาธารณะ พูล proxy ที่ใช้ร่วมกัน หรือ IP ขาออก VPS ที่เปลี่ยนบ่อย ก่อนตั้งค่า ให้ตรวจประเภท IP และคะแนนความเสี่ยงปัจจุบันด้วยการตรวจความสะอาด
IP คงที่เทียบกับการสลับบ่อย
IP ที่เปลี่ยนไปเพราะ ISP เชื่อมต่อใหม่ตามปกติ มักต่างจากการที่บัญชีกระโดดข้ามประเทศ สิ่งที่สำคัญกว่าคือการสลับไปมาระหว่างหลายประเทศ หลาย ASN และหลายอุปกรณ์บ่อย ๆ ในเวลาสั้น ๆ — ซึ่งเพิ่มโอกาสที่บัญชีจะถูกตรวจสอบด้านความปลอดภัย
บังคับใช้ TCP หลีกเลี่ยง UDP/QUIC
QUIC (UDP 443) มีแนวโน้มเกิดแพ็กเก็ตหาย หมดเวลา หรือถูกส่งต่อผิดคาดภายใต้ proxy หรือไฟร์วอลล์ขององค์กรบางแบบ หากเจอการตัดการเชื่อมต่อเป็นพัก ๆ ให้ลองปิด QUIC หรือบังคับให้ทราฟฟิกที่เกี่ยวกับ Claude ใช้ TCP เท่านั้นแล้วทดสอบอีกครั้ง
"network": "tcp" # หรือปิด QUIC ที่ระดับไคลเอนต์
ลายนิ้วมือ TLS ควรดูเหมือนเบราว์เซอร์
ไคลเอนต์แต่ละตัวอาจมีลักษณะ TLS handshake ต่างกัน หากสาย proxy เปลี่ยนพฤติกรรม TLS แทรกใบรับรอง หรือใช้ลายนิ้วมือไคลเอนต์ที่ผิดปกติอย่างชัดเจน อาจทำให้เชื่อมต่อไม่สำเร็จหรือถูกยืนยันเพิ่มเติม ควรใช้ไคลเอนต์ที่เป็นที่ยอมรับและการตั้งค่า TLS มาตรฐาน
"tls": {
"fingerprint": "chrome"
}ให้เส้นทาง DNS และ HTTP สอดคล้องกัน
resolver ของ DNS ขาออก HTTP และขาออกของเบราว์เซอร์ควรมาจากเส้นทางเครือข่ายเดียวกัน หาก DNS resolve ในเครื่องขณะที่ HTTP ออกผ่าน proxy ภูมิภาคที่ได้จากการ resolve กับภูมิภาคที่เข้าถึงอาจไม่ตรงกัน ใช้ DoH/DoT ที่เชื่อถือได้ก็ได้ แต่สิ่งสำคัญคือต้องยืนยันว่ากฎการแยกเส้นทางครอบคลุมทราฟฟิก DNS จริง
"dns": {
"servers": ["https://1.1.1.1/dns-query"]
}ตรวจเส้นทาง IPv6 dual-stack
หาก proxy หรือกฎการแยกเส้นทางครอบคลุมเฉพาะ IPv4 ทราฟฟิก IPv6 อาจไปอีกเส้นทางหนึ่ง ทำให้ HTTP / DNS / WebRTC เห็นขาออกที่ไม่สอดคล้องกัน ไม่จำเป็นต้องปิด IPv6 เสมอไป แต่ควรตรวจความสอดคล้องของ dual-stack ก่อน ดูรายละเอียดที่ ความเสี่ยงของ IPv6 dual-stack
ipv6 = false # หรือตั้ง domainStrategy: "UseIPv4" ใน proxy
กฎการแยกเส้นทางเฉพาะสำหรับโดเมนของ Claude
เอกสารทางการระบุว่าการเข้าถึงเครือข่ายของ Claude Code อย่างน้อยต้องมี api.anthropic.com, claude.ai, statsig.anthropic.com และ sentry.io แนะนำให้สร้างกฎการแยกเส้นทางเฉพาะสำหรับโดเมนเหล่านี้เพื่อให้แก้ปัญหาและตรวจสอบย้อนหลังได้ง่ายขึ้น ดู กฎการแยกเส้นทางของ Claude Code
ส่งทราฟฟิก CDN / auth / การมอนิเตอร์ผ่าน proxy ด้วย
Claude Web การเข้าสู่ระบบ เอกสาร และไฟล์สแตติกอาจใช้ CDN หรือบริการของบุคคลที่สามต่างกันไปตามเวอร์ชัน อย่าฮาร์ดโค้ดเพียงโดเมนหลักเดียว — ใช้โดเมนที่จำเป็นตามเอกสารทางการเป็นพื้นฐาน แล้วใช้การดักจับแพ็กเก็ตหรือล็อกในเครื่องเพื่อเพิ่มโดเมนไฟล์สแตติกที่เข้าถึงจริง
รักษาการเชื่อมต่อให้คงอยู่
การตัดและเชื่อมต่อใหม่บ่อย ๆ เพิ่มความหน่วงและทำให้แก้ปัญหาสาย proxy ได้ยากขึ้น ไคลเอนต์ proxy เปิด TCP keep-alive ในระดับที่เหมาะสมได้ ส่วนจะเปิด connection multiplexing (mux) หรือไม่ขึ้นกับคุณภาพสาย — หากพบการค้างจาก multiplexing หรือการจำกัดความเร็วต่อการเชื่อมต่อ ให้ปิดแล้วเปรียบเทียบ
จำกัดคำขอพร้อมกันไม่เกิน 5
อย่าครอบการเรียก Claude Code ด้วย worker ที่ทำงานพร้อมกันจำนวนมาก การทำงานพร้อมกันมากเกินไปอาจทำให้ติด rate limit การเชื่อมต่อต้องรอคิว หรือเกตเวย์ขององค์กรจำกัดปริมาณ เกณฑ์จริงขึ้นอยู่กับแพ็กเกจบัญชี นโยบายขององค์กร และการตอบกลับของ API
ปรับเส้นทางเครือข่ายให้เหมาะสม
เลือกขาออกที่มีแพ็กเก็ตหายน้อย jitter ต่ำ และมีเส้นทางไปยัง Anthropic API ที่เสถียรก่อน — อย่าดูแค่ระยะทางทางภูมิศาสตร์ ใช้การตรวจการรั่วไหลร่วมกับความหน่วงของคำขอ Claude Code จริงในการตัดสิน
สรุป
ความเสถียรของ Claude Code = ข้อกำหนดเครือข่ายอย่างเป็นทางการ + การตั้งค่า proxy + ความสอดคล้องของเส้นทาง DNS/IPv6 ก่อนอื่นให้ตรวจว่าเข้าถึง api.anthropic.com, claude.ai, statsig.anthropic.com และ sentry.io ได้ แล้วจึงตรวจ proxy ใบรับรอง และเส้นทาง dual-stack