Codex مدام دوباره وصل می‌شود؟ DNS و مسیریابی Clash را بررسی کنید

خطاهای Codex مانند Reconnecting...، stream disconnected before completion و error sending request می‌توانند به تداخل DNS یا مسیریابی نادرست Clash مربوط باشند. این راهنما توضیح می‌دهد چگونه این احتمال را بررسی کنید، یک بهبود هدفمند Clash Verge Rev اعمال کنید، و نتیجه را تأیید کنید.

گزارش‌های جامعه واقعاً چه چیزی را نشان می‌دهند

کاربران Reddit گزارش داده‌اند که وظایفی که chatgpt.com/backend-api/codex/responses را هدف می‌گیرند قطع شده‌اند، تلاش‌های مکرر برای reconnect رخ داده، و خطاهای مربوط به response-body دیده شده است. این گزارش‌ها فقط نشانه‌ها را ثابت می‌کنند، نه یک تشخیص DNS را. درخواست قطع‌شده، حلقه reconnect

یک بحث جداگانه از شکست‌ها هنگام remote context compaction توضیح می‌دهد. یکی از commenters پیشنهاد می‌کند proxy را بررسی کنید، اما آن بحث علتِ تأییدشده‌ای را ثابت نمی‌کند. بحث compaction

گزارش‌ها در X پرسش‌های مشابهی را نشان می‌دهند: پستی در 9 سپتامبر از شکست‌های مداوم stream می‌گوید، در حالی که پستی در 6 سپتامبر یک SSE idle timeout را هنگام remote compaction گزارش می‌کند. هیچ‌کدام مقایسه‌ای درباره DNS ارائه نمی‌کنند. این‌ها نمونه‌های مفیدی از مشکلات کاربران هستند، اما علت مشترکی را ثابت نمی‌کنند. گزارش stream در X، گزارش compaction در X

نشانه	چه چیزی را بررسی کنید
timeout فوری همراه با خطای resolver	DNS، دسترس‌پذیری node، و اینکه آیا ترافیک وارد Clash می‌شود
ChatGPT در مرورگر کار می‌کند اما Codex شکست می‌خورد	تفاوت‌ها در proxy، DNS، گواهی‌ها، و egress
خروجی شروع می‌شود، سپس stream قطع می‌شود	اتصال‌های بلندمدت، تغییرات شبکه، و خطاهای سرویس
فقط گفت‌وگوهای طولانی یا compaction شکست می‌خورند	با یک کار کوچک و جدید مقایسه کنید؛ session و خطاهای سرور را بررسی کنید
HTTP 401، 403، 429، یا 5xx	منبع و بدنه response را برای احراز هویت، policy، محدودیت‌ها، یا شکست‌های سرویس بررسی کنید

وضعیت سرویس OpenAI را بررسی کنید و زمان و نسخه client را ثبت کنید. برای چت‌های گیرکرده، OpenAI همچنین توصیه می‌کند approvals در انتظار را بررسی کنید و یک چت جدید کوچک و متمرکز را امتحان کنید. نسخه‌های desktop و CLI ممکن است متفاوت باشند. عیب‌یابی رسمی

یک مورد محلی: یک پاسخ DNS غیرمنتظره DIRECT را فعال کرد

در یک بررسی ثبت‌شده در macOS با استفاده از Clash Verge Rev و Mihomo، nodeهای proxy قابل دسترس بودند، اما chatgpt.com با یک rule از نوع GeoIP/CN تطبیق پیدا کرد و یک اتصال مستقیم را تلاش کرد که timeout شد. مقایسه با DNS رمزنگاری‌شده‌ای که از طریق proxy می‌رسید، یک پاسخ غیرعادی در مسیر resolution محلی نشان داد.

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

دو مسئله پیکربندی باید بررسی شوند: مسیر resolution و تصمیم routing. این مورد ثبت‌شده نه یک benchmark است و نه دلیلی بر این‌که سایر شکست‌های Codex همان علت را دارند. یک پاسخ غیرعادی به‌تنهایی هم نمی‌تواند واسطه مسئول را شناسایی کند یا به‌طور مشخص DNS cache poisoning را ثابت کند.

پیش از تغییر پیکربندی، تشخیص دهید

لاگ اتصال را بررسی کنید

نام میزبان واقعی را در خطا جست‌وجو کنید، از جمله chatgpt.com یا openai.com. rule تطبیق‌داده‌شده، زنجیره اتصال، و خطا را در زمان شکست ثبت کنید. اتصالی که باید از proxy استفاده کند اما DIRECT را انتخاب می‌کند، نیازمند بازبینی ترتیب ruleها است. Mihomo ruleهای routing را از بالا به پایین ارزیابی می‌کند. مستندات routing

اگر هیچ اتصال تطبیق‌داده‌شده‌ای دیده نمی‌شود، ابتدا مشخص کنید آیا آن client از Clash استفاده می‌کند. موفق بودن مرورگر مسیر استفاده‌شده توسط یک process جداگانه را ثابت نمی‌کند.

مسیرهای resolution را مقایسه کنید

در 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'

این درخواست از رابط JSON DNS کلادفلر استفاده می‌کند. پنل اتصال را بررسی کنید: یک proxy محلی صریح، ورود به Clash را تضمین می‌کند، اما ruleهای Clash همچنان egress نهایی را تعیین می‌کنند.

تفاوتِ صرفِ آدرس‌های IP به‌تنهایی اثبات تداخل نیست. انتخاب CDN، کش، خانواده‌های آدرس، و Fake-IP می‌توانند تفاوت‌ها را توضیح دهند. یک آدرس مصنوعی از بازه Fake-IP در Clash ذاتاً مشکوک نیست. یک پاسخ غیرعادی را با route نادرست و شکست همبسته کنید، سپس آن را با مسیر شبکه تأییدشده دیگری مقایسه کنید. با فعال بودن TUN، حتی dig @resolver هم ممکن است رهگیری شود؛ این به‌طور خودکار یک آزمون upstream مستقل نیست.

اعمال یک بهبود هدفمند Clash Verge Rev

این الگو به Clash Verge Rev با Mihomo، یک subscription موجود، و یک node پروکسیِ کارآمد نیاز دارد. این یک Script برای subscription است، نه یک profile کاملِ مستقل. ابتدا از پیکربندی فعلی نسخه پشتیبان بگیرید. اگر از قبل از یک script استفاده می‌کنید، این تغییر را در تابع main(config) موجود آن ادغام کنید. پیکربندی نهاییِ runtime را پس از همه مراحل enhancement بررسی کنید. مستندات Script در Clash Verge Rev

CODEX_PROXY_GROUP را روی یک گروه موجود تنظیم کنید و یک گره پراکسیِ کار می‌کند را در آن گروه انتخاب کنید. NODE_DNS را روی یک resolver از نوع DoH تنظیم کنید که پیش از اتصال پراکسی کار می‌کند و نام‌های میزبانِ گره را به‌درستی resolve می‌کند. مثال AliDNS برای اعتبارسنجی در یک شبکه داخل چینِ سرزمین اصلی در نظر گرفته شده است؛ اگر مناسب نیست آن را جایگزین کنید. این مورد برای resolve کردن دامنه‌های هوش مصنوعیِ زیر استفاده نمی‌شود.

// 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

اسکریپتِ هدف‌گیری‌شده، تنظیمات fallback موجود را حفظ می‌کند. پیش از جایگزین کردن آن‌ها، وابستگی‌های گسترده‌تر DNS را جداگانه بررسی کنید. همچنین mapping های قدیمی hosts یا policy های دقیق‌تر و متعارض را بررسی کنید.

TUN را جداگانه بررسی کنید

برای فرایندهایی که از پراکسی سیستم استفاده نمی‌کنند، 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 است. به‌جای فرض کردن اینکه این گزینه همهٔ درخواست‌ها را پوشش می‌دهد، رفتار resolver و interface را بررسی کنید. مرجع TUN

پیکربندی، routing، و Codex را جداگانه بررسی کنید

ابتدا پیکربندی نهایی را برای خطاها، ارجاع‌های گروه، و ترتیب rule ها بررسی کنید. اگر CLI مربوط به Mihomo در دسترس است، mihomo -t -f <final-config-path> بررسی می‌کند که آیا پیکربندی parse می‌شود یا نه. این موضوع اتصال‌پذیری را ثابت نمی‌کند.

سپس routing واقعی اتصال را بررسی کنید و یک probe HTTPS با تأیید certificate را از طریق پورت 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/

پاسخی از سرویسِ موردنظر پس از موفقیتِ تأیید certificate، یک تبادل HTTP برای این probe را برقرار می‌کند. یک 401 یا 403 همچنان می‌تواند دسترسی را مسدود کند. این کار ثابت نمی‌کند که یک درخواست authenticated Codex کار می‌کند، و غیرفعال کردن تأیید certificate این بررسی را نامعتبر می‌کند.

در نهایت، یک تسک کوچک را در کلاینتی که ابتدا شکست خورده بود کامل کنید. یک CLI نصب‌شده و authenticated می‌تواند بررسی اختیاری زیر را اجرا کند، که یک درخواست واقعی مدل می‌سازد و از سهمیهٔ حساب استفاده می‌کند:

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

موفقیت CLI فقط همان درخواست CLI را تأیید می‌کند؛ اگر خطا در برنامهٔ دسکتاپ رخ داده است، آن را جداگانه آزمایش کنید. پس از به‌روزرسانی اشتراک، تغییر شبکه، و sleep/wake دوباره بررسی کنید. لایه‌های بعدی پیکربندی یا نام‌گذاری مجدد گروه‌ها هنوز هم می‌توانند یک enhancement را خراب کنند.

پرسش‌های متداول

آیا تغییر DNS سیستم به 8.8.8.8 کافی است؟

نه لزوماً. یک آدرس resolver به‌تنهایی encryption، routing پراکسی، یا دسترس‌پذیری را برقرار نمی‌کند. resolver، transport، و egress را با هم بررسی کنید.

چرا وقتی Clash در حال اجرا است Codex شکست می‌خورد؟

ممکن است فرایند از پراکسی عبور نکند، با یک rule مستقیم منطبق شود، یا به DNS گره‌ای وابسته باشد که در دسترس نیست. ممکن است مشکل اصلاً به DNS مربوط نباشد. پیش از تغییر هم‌زمان چند تنظیم، اتصال واقعی را پیدا کنید.

اگر باز هم قطع می‌شود چه؟

اگر DNS، TLS، و routing کار می‌کنند، وضعیت سرویس، اندازهٔ conversation، نسخهٔ client، پایداری اتصال گره، و متن دقیق خطا را بررسی کنید. OpenAI محل‌های feedback و log را مستند کرده است؛ پیش از به‌اشتراک‌گذاری، log ها را برای secrets بررسی کنید. عیب‌یابی و log ها

چگونه تغییر را برگردانم؟

Script افزوده‌شده را غیرفعال کنید و profile پشتیبان‌گرفته‌شده، تنظیمات TUN، و هر تنظیم DNS سیستم را که تغییر داده‌اید، بازیابی کنید. یک معماری جداگانهٔ proxy-providers می‌تواند بعداً subscription های گره را از DNS و rule های local جدا کند، اما برای این رفع مشکلِ هدف‌گیری‌شده ضروری نیست.

برای مراحل نصب و import، به راه‌اندازی Clash Verge مراجعه کنید. برای سایر خطاها، به عیب‌یابی Clash مراجعه کنید. می‌توانید از این فرایند تشخیصی با یک subscription سازگارِ موجود استفاده کنید؛ خرید یک سرویس دیگر پیش‌نیاز آزمایش DNS نیست.