Codex เชื่อมต่อใหม่อยู่ตลอด? ตรวจสอบ DNS และการกำหนดเส้นทางของ Clash

ข้อผิดพลาดของ Codex เช่น Reconnecting..., stream disconnected before completion, และ error sending request อาจเกี่ยวข้องกับการรบกวนจาก DNS หรือการกำหนดเส้นทางของ Clash ที่ไม่ถูกต้อง คู่มือนี้อธิบายวิธีตรวจสอบความเป็นไปได้นั้น ใช้การปรับปรุง Clash Verge Rev แบบเจาะจง และตรวจสอบผลลัพธ์

สิ่งที่รายงานจากชุมชนแสดงให้เห็นจริง ๆ

ผู้ใช้ Reddit รายงานว่างานที่ส่งไปยัง chatgpt.com/backend-api/codex/responses ถูกขัดจังหวะ มีการพยายามเชื่อมต่อใหม่ซ้ำ ๆ และเกิดข้อผิดพลาดใน response-body รายงานเหล่านี้ยืนยันอาการ ไม่ใช่การวินิจฉัยว่าเป็น DNS โดยตรง Interrupted request, reconnection loop

การสนทนาอีกชุดหนึ่งอธิบายความล้มเหลวระหว่างการ compaction ของ remote context ผู้แสดงความคิดเห็นคนหนึ่งแนะนำให้ตรวจสอบพร็อกซี แต่การสนทนาดังกล่าวไม่ได้ยืนยันสาเหตุที่ตรวจสอบแล้ว Compaction discussion

รายงานบน X แสดงคำถามที่คล้ายกัน: โพสต์วันที่ 9 กันยายนอธิบายความล้มเหลวของสตรีมที่เกิดขึ้นต่อเนื่อง ขณะที่โพสต์วันที่ 6 กันยายนรายงาน SSE idle timeout ระหว่างการ compaction จากระยะไกล ทั้งสองกรณีไม่ได้ให้การเปรียบเทียบ DNS ข้อมูลเหล่านี้เป็นตัวอย่างที่มีประโยชน์ของปัญหาผู้ใช้ แต่ไม่ได้ยืนยันสาเหตุร่วมกัน X stream report, X compaction report

อาการ	สิ่งที่ควรตรวจสอบ
หมดเวลาในทันทีพร้อมข้อผิดพลาดของ resolver	DNS, การเข้าถึงโหนด, และว่าทราฟฟิกเข้าสู่ Clash หรือไม่
ChatGPT ใช้ได้ในเบราว์เซอร์แต่ Codex ล้มเหลว	ความแตกต่างของพร็อกซี, DNS, ใบรับรอง, และขาออก
เอาต์พุตเริ่มต้นขึ้น แต่สตรีมตัดการเชื่อมต่อ	การเชื่อมต่อระยะยาว, การเปลี่ยนแปลงเครือข่าย, และข้อผิดพลาดของบริการ
เฉพาะบทสนทนายาวหรือการ compaction ที่ล้มเหลว	เปรียบเทียบกับงานใหม่ขนาดเล็ก; ตรวจสอบ session และข้อผิดพลาดของเซิร์ฟเวอร์
HTTP 401, 403, 429, หรือ 5xx	ตรวจสอบแหล่งที่มาของการตอบกลับและ body เพื่อดูการยืนยันตัวตน, นโยบาย, ข้อจำกัด, หรือความล้มเหลวของบริการ

ตรวจสอบ OpenAI service status และบันทึกเวลาและเวอร์ชันของไคลเอนต์ สำหรับแชตที่ค้าง OpenAI ยังแนะนำให้ตรวจสอบการอนุมัติที่รอดำเนินการและลองแชตใหม่ที่เล็กลงและเจาะจงมากขึ้น เวอร์ชันเดสก์ท็อปและ CLI อาจแตกต่างกัน Official troubleshooting

กรณีในเครื่อง: คำตอบ DNS ที่ไม่คาดคิดทำให้เกิด DIRECT

ในการตรวจสอบ macOS ที่บันทึกไว้ครั้งหนึ่งโดยใช้ Clash Verge Rev และ Mihomo โหนดพร็อกซีสามารถเข้าถึงได้ แต่ chatgpt.com ตรงกับกฎ GeoIP/CN และพยายามเชื่อมต่อโดยตรงซึ่งหมดเวลา การเปรียบเทียบกับ DNS แบบเข้ารหัสที่เข้าถึงผ่านพร็อกซีแสดงคำตอบที่ผิดปกติในเส้นทางการ resolve ภายในเครื่อง

Request to chatgpt.com
  → anomalous DNS answer
  → no earlier matching OpenAI domain rule
  → GeoIP selects DIRECT
  → connection times out and Codex retries

มีสองประเด็นการกำหนดค่าที่ต้องจัดการ: เส้นทางการ resolve และการตัดสินใจในการกำหนดเส้นทาง กรณีที่บันทึกไว้นี้ไม่ใช่เกณฑ์มาตรฐานหรือหลักฐานว่าความล้มเหลวอื่น ๆ ของ Codex มีสาเหตุเดียวกัน คำตอบที่ผิดปกติเพียงอย่างเดียวก็ไม่สามารถระบุส่วนกลางที่รับผิดชอบหรือยืนยันว่าเป็น DNS cache poisoning โดยเฉพาะได้

วินิจฉัยก่อนเปลี่ยนการตั้งค่า

ตรวจสอบบันทึกการเชื่อมต่อ

ค้นหา hostname ที่แท้จริงในข้อผิดพลาด รวมถึง chatgpt.com หรือ openai.com บันทึกกฎที่จับคู่, chain การเชื่อมต่อ, และข้อผิดพลาดในเวลาที่เกิดความล้มเหลว การเชื่อมต่อที่ควรใช้พร็อกซีแต่กลับเลือก DIRECT ควรตรวจสอบลำดับกฎ Mihomo ประเมินกฎการกำหนดเส้นทางจากบนลงล่าง Routing documentation

หากไม่พบการเชื่อมต่อที่ตรงกัน ให้เริ่มจากการยืนยันว่าไคลเอนต์นั้นใช้ Clash หรือไม่ เบราว์เซอร์ใช้ได้ไม่ได้ยืนยันเส้นทางที่กระบวนการอื่นใช้

เปรียบเทียบเส้นทางการ resolve

บน macOS ให้ตรวจสอบตัว resolver ของระบบและคำตอบปัจจุบัน:

scutil --dns
dscacheutil -q host -a name chatgpt.com

สำหรับการเปรียบเทียบแบบเข้ารหัส ให้แทนที่ 7890 ด้วยพอร์ต HTTP/mixed ของ Clash ของคุณ:

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=chatgpt.com&type=A'

คำขอใช้ Cloudflare’s DNS JSON interface. ตรวจสอบแผงการเชื่อมต่อ: พร็อกซีท้องถิ่นแบบ explicit รับประกันการเข้าสู่ Clash แต่กฎของ Clash ยังคงเป็นตัวกำหนดทางออกสุดท้าย

IP address ที่ต่างกันเพียงอย่างเดียวไม่ใช่หลักฐานของการรบกวน การเลือก CDN, การแคช, ครอบครัวของ address, และ Fake-IP สามารถอธิบายความแตกต่างได้ ที่อยู่สังเคราะห์จากช่วง Fake-IP ของ Clash ไม่ได้มีความน่าสงสัยโดยเนื้อแท้ ให้นำคำตอบที่ผิดปกติมาเชื่อมโยงกับเส้นทางที่ไม่ถูกต้องและความล้มเหลว จากนั้นเปรียบเทียบกับเส้นทางเครือข่ายอื่นที่ยืนยันแล้ว เมื่อเปิด TUN อยู่ แม้แต่ dig @resolver ก็อาจถูกดักได้ จึงไม่ใช่การทดสอบ upstream ที่เป็นอิสระโดยอัตโนมัติ

ใช้การปรับปรุง Clash Verge Rev แบบเจาะจง

เทมเพลตนี้ต้องใช้ Clash Verge Rev กับ Mihomo, subscription ที่มีอยู่แล้ว, และโหนดพร็อกซีที่ใช้งานได้ เป็น Script สำหรับ subscription ไม่ใช่โปรไฟล์แบบสแตนด์อโลนที่สมบูรณ์ สำรองการตั้งค่าปัจจุบันก่อน หากคุณใช้งาน script อยู่แล้ว ให้ผสานการเปลี่ยนแปลงเข้าไปในฟังก์ชัน main(config) ที่มีอยู่ ตรวจสอบการกำหนดค่าขณะรันไทม์สุดท้ายหลังจากขั้นตอน enhancement ทั้งหมด Clash Verge Rev Script documentation

ตั้งค่า CODEX_PROXY_GROUP ให้เป็นกลุ่มที่มีอยู่ และเลือกโหนดพร็อกซีที่ใช้งานได้ในกลุ่มนั้น ตั้งค่า NODE_DNS ให้เป็นตัวแก้ไข DoH ที่ใช้งานได้ก่อนที่พร็อกซีจะเชื่อมต่อ และสามารถ resolve ชื่อโฮสต์ของโหนดได้อย่างถูกต้อง ตัวอย่าง AliDNS มีไว้เพื่อการตรวจสอบบนเครือข่ายในจีนแผ่นดินใหญ่ ให้เปลี่ยนเมื่อไม่เหมาะสม โดยไม่ได้ใช้เพื่อ resolve โดเมน AI ด้านล่าง

// Clash Verge Rev subscription Script. Use with an existing Mihomo profile.
// Replace this with the exact name of a working proxy group in that profile.
const CODEX_PROXY_GROUP = "REPLACE_WITH_EXISTING_PROXY_GROUP";

// Example bootstrap resolver for a mainland-China network. Verify reachability
// and node-hostname answers on your network, or replace with your trusted DoH.
// It must work BEFORE the proxy is established. It does not resolve AI domains.
const NODE_DNS = ["https://223.5.5.5/dns-query#DIRECT"];

function main(config) {
  const groups = config["proxy-groups"] || [];
  if (!groups.some((group) => group.name === CODEX_PROXY_GROUP)) {
    throw new Error("Set CODEX_PROXY_GROUP to an existing working proxy group.");
  }
  if (/[#&,\r\n]/.test(CODEX_PROXY_GROUP)) {
    throw new Error("Use a proxy group name without #, &, commas or newlines.");
  }

  const domains = ["chatgpt.com", "openai.com", "oaistatic.com", "oaiusercontent.com"];
  const doh = [
    "https://1.1.1.1/dns-query#" + CODEX_PROXY_GROUP,
    "https://8.8.8.8/dns-query#" + CODEX_PROXY_GROUP,
  ];
  const dns = config.dns || {};
  const policy = Object.assign({}, dns["nameserver-policy"] || {});
  domains.forEach((domain) => { policy["+." + domain] = doh.slice(); });
  dns.enable = true;
  dns["nameserver-policy"] = policy;
  dns["proxy-server-nameserver"] = NODE_DNS.slice();
  if (!Array.isArray(dns.nameserver) || dns.nameserver.length === 0) {
    dns.nameserver = NODE_DNS.slice();
  }
  config.dns = dns;

  const oldRules = Array.isArray(config.rules) ? config.rules : [];
  const aiRules = domains.map((domain) =>
    "DOMAIN-SUFFIX," + domain + "," + CODEX_PROXY_GROUP
  );
  config.rules = aiRules.concat(oldRules.filter((rule) => !aiRules.includes(rule)));
  return config;
}

สคริปต์จะเพิ่มนโยบาย DNS เฉพาะโดเมน และแทรกกฎพร็อกซีไว้ด้านหน้า ในขณะที่ยังคงกฎและนโยบายโดเมนอื่นๆ ไว้เหมือนเดิม สคริปต์นี้เปลี่ยนวิธีการ resolve ชื่อโฮสต์ของโหนด ชื่อโดเมนสี่ส่วนต่อท้ายเป็นขอบเขตเริ่มต้น ไม่ใช่รายการที่ครอบคลุมทุกฟีเจอร์ของ Codex ผู้ให้บริการแบบกำหนดเอง บริการ MCP หรือการดาวน์โหลดงานทั้งหมด

Mihomo รองรับ nameserver-policy เฉพาะโดเมน และส่วนต่อท้ายพร็อกซีแบบชัดเจนบนที่อยู่เซิร์ฟเวอร์ DNS การ resolve โหนดต้องมีเส้นทางอิสระเพื่อหลีกเลี่ยงการพึ่งพาแบบวนลูป เอกสารอ้างอิงการตั้งค่า DNS

สคริปต์ที่มุ่งเป้าไว้นี้จะคงค่าทางเลือกสำรองที่มีอยู่ไว้ ตรวจสอบการพึ่งพา DNS ที่กว้างกว่านี้แยกต่างหากก่อนแทนที่ และตรวจสอบด้วยว่ามีการแมป hosts ที่ล้าสมัยหรือนโยบายที่เฉพาะเจาะจงกว่าซึ่งขัดแย้งกันอยู่หรือไม่

ตรวจสอบ TUN แยกต่างหาก

สำหรับกระบวนการที่ไม่ใช้ system proxy ให้เปิด TUN ใน Clash Verge Rev และยืนยันว่ากำลังทำงานอยู่ รวมฟิลด์ต่อไปนี้เข้าไปในอ็อบเจ็กต์ TUN ที่มีอยู่ โดยคงการตั้งค่าอื่นๆ ไว้:

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

สิ่งเหล่านี้ครอบคลุม DNS แบบ UDP และ TCP บนพอร์ต 53 Mihomo ระบุข้อจำกัดสำหรับ DNS ที่ส่งไปยัง LAN บน macOS และ Windows; DNS แบบเข้ารหัสที่แอปจัดการเองก็อยู่นอกกฎพอร์ต 53 เหล่านี้ด้วย ให้ตรวจสอบพฤติกรรมของตัวแก้ไขและอินเทอร์เฟซแทนที่จะสันนิษฐานว่าสวิตช์ครอบคลุมทุกคำขอ เอกสารอ้างอิง TUN

ตรวจสอบการตั้งค่า การกำหนดเส้นทาง และ Codex แยกกัน

เริ่มจากตรวจสอบคอนฟิกสุดท้ายว่ามีข้อผิดพลาด การอ้างอิงกลุ่ม และลำดับของกฎหรือไม่ หากมี Mihomo CLI ให้ใช้ mihomo -t -f <final-config-path> เพื่อตรวจว่าคอนฟิกแยกวิเคราะห์ได้หรือไม่ ซึ่งไม่ได้พิสูจน์ว่าการเชื่อมต่อใช้งานได้

จากนั้นตรวจสอบการกำหนดเส้นทางของการเชื่อมต่อจริง และรันทดสอบ HTTPS ที่ยืนยันใบรับรองผ่านพอร์ต local จริงของคุณ:

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'HTTP=%{http_code} TLS=%{time_appconnect}s TOTAL=%{time_total}s\n' \
  https://chatgpt.com/

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

สุดท้าย ให้ทำงานขนาดเล็กใน client ที่เคยล้มเหลวมาก่อน CLI ที่ติดตั้งและยืนยันตัวตนแล้วสามารถรันการตรวจสอบเสริมต่อไปนี้ ซึ่งจะส่งคำขอ model จริงและใช้โควตาของบัญชี:

codex exec --skip-git-repo-check --sandbox read-only \
  'Reply with exactly: PONG. Do not use tools.'

ความสำเร็จของ CLI จะยืนยันเฉพาะคำขอของ CLI เท่านั้น; หากความล้มเหลวเกิดขึ้นที่เดสก์ท็อปแอป ให้ทดสอบแอปนั้นแยกต่างหาก ตรวจสอบอีกครั้งหลังการอัปเดตการสมัครใช้งาน การเปลี่ยนแปลงเครือข่าย และการ sleep/wake การกำหนดค่าชั้นถัดไปหรือการเปลี่ยนชื่อกลุ่มยังอาจทำให้ส่วนปรับปรุงล้มเหลวได้

คำถามที่พบบ่อย

การเปลี่ยน system DNS เป็น 8.8.8.8 เพียงพอหรือไม่?

ไม่จำเป็นเสมอไป ที่อยู่ตัวแก้ไขเพียงอย่างเดียวไม่ได้ยืนยันการเข้ารหัส การกำหนดเส้นทางพร็อกซี หรือการเข้าถึงได้จริง ตรวจสอบตัวแก้ไข การส่งผ่าน และทางออกพร้อมกัน

ทำไม Codex ถึงล้มเหลวขณะที่ Clash กำลังทำงานอยู่?

กระบวนการอาจข้ามพร็อกซี ตรงกับกฎ direct หรือขึ้นอยู่กับ DNS ของโหนดที่ไม่พร้อมใช้งาน ปัญหาอาจไม่เกี่ยวกับ DNS ด้วยก็ได้ ค้นหาเส้นทางการเชื่อมต่อจริงก่อนที่จะเปลี่ยนหลายการตั้งค่าพร้อมกัน

ถ้ายังตัดการเชื่อมต่ออยู่ล่ะ?

หาก DNS, TLS และการกำหนดเส้นทางทำงานได้ ให้ตรวจสอบสถานะของบริการ ขนาดการสนทนา เวอร์ชันไคลเอนต์ ความเสถียรของการเชื่อมต่อโหนด และเนื้อหาข้อผิดพลาดที่แน่ชัด OpenAI มีเอกสารเกี่ยวกับตำแหน่งสำหรับข้อเสนอแนะและบันทึก; โปรดตรวจบันทึกหาความลับก่อนแชร์ การแก้ปัญหาและบันทึก

จะย้อนกลับการเปลี่ยนแปลงได้อย่างไร?

ปิดใช้งาน Script ที่เพิ่มเข้ามา และกู้คืนโปรไฟล์ที่สำรองไว้ การตั้งค่า TUN และการตั้งค่า system DNS ใดๆ ที่คุณเปลี่ยนไว้ สถาปัตยกรรม proxy-providers แยกต่างหากสามารถแยกการสมัครรับโหนดออกจาก local DNS และ rules ได้ในภายหลัง แต่ไม่จำเป็นสำหรับการแก้ไขเฉพาะจุดนี้

สำหรับขั้นตอนการติดตั้งและการนำเข้า ดู การตั้งค่า Clash Verge สำหรับความล้มเหลวอื่นๆ ดู การแก้ปัญหา Clash คุณสามารถใช้กระบวนการวินิจฉัยนี้กับการสมัครใช้งานที่เข้ากันได้ที่มีอยู่แล้ว; การซื้อบริการอื่นไม่ใช่ข้อกำหนดล่วงหน้าสำหรับการทดสอบ DNS