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 کی تشخیص کو نہیں۔ منقطع درخواست، دوبارہ منسلک ہونے کا چکر

ایک علیحدہ بحث remote context compaction کے دوران ناکامیوں کو بیان کرتی ہے۔ ایک تبصرہ نگار پراکسی کی جانچ کی تجویز دیتا ہے، لیکن یہ بحث کسی تصدیق شدہ وجہ کو ثابت نہیں کرتی۔ compaction بحث

X پر رپورٹس ملتے جلتے سوالات دکھاتی ہیں: 9 ستمبر کی ایک پوسٹ مسلسل stream ناکامیوں کو بیان کرتی ہے، جبکہ 6 ستمبر کی ایک پوسٹ remote compaction کے دوران SSE idle timeout کی اطلاع دیتی ہے۔ ان میں سے کوئی بھی DNS موازنہ فراہم نہیں کرتی۔ یہ صارفین کے مسائل کی مفید مثالیں ہیں، لیکن یہ کسی مشترک وجہ کو ثابت نہیں کرتیں۔ X stream رپورٹ، X compaction رپورٹ

علامت	کس چیز کی جانچ کریں
resolver کی غلطی کے ساتھ فوری timeout	DNS، node تک رسائی، اور آیا ٹریفک Clash میں داخل ہو رہی ہے
ChatGPT براؤزر میں کام کرتا ہے لیکن Codex ناکام ہوتا ہے	پراکسی، DNS، certificates، اور egress میں فرق
آؤٹ پٹ شروع ہوتا ہے، پھر stream منقطع ہو جاتی ہے	طویل المدت connections، network تبدیلیاں، اور service کی غلطیاں
صرف لمبی گفتگوئیں یا compaction ناکام ہوتے ہیں	ایک چھوٹے نئے کام سے موازنہ کریں؛ session اور server کی غلطیوں کی جانچ کریں
HTTP 401, 403, 429, or 5xx	authentication، policy، limits، یا service ناکامیوں کے لیے response origin اور body کا معائنہ کریں

OpenAI service status چیک کریں اور وقت اور client version ریکارڈ کریں۔ اٹکی ہوئی chats کے لیے، OpenAI یہ بھی تجویز کرتا ہے کہ pending approvals چیک کریں اور ایک چھوٹی، مرکوز نئی chat آزمائیں۔ Desktop اور CLI versions مختلف ہو سکتے ہیں۔ سرکاری خرابی دور کرنے کی رہنمائی

ایک مقامی کیس: غیر متوقع DNS جواب نے DIRECT کو متحرک کر دیا

Clash Verge Rev اور Mihomo استعمال کرنے والی ایک ریکارڈ شدہ macOS جانچ میں، پراکسی nodes قابلِ رسائی تھے، لیکن chatgpt.com ایک GeoIP/CN rule سے میل کھا رہا تھا اور ایک direct connection کی کوشش کر رہا تھا جو timeout ہو گئی۔ پراکسی کے ذریعے پہنچنے والے encrypted DNS کے ساتھ موازنے نے مقامی resolution path میں ایک غیر معمولی جواب دکھایا۔

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

حل کرنے کے لیے ترتیب کے دو مسائل ہیں: resolution path اور routing decision۔ یہ ریکارڈ شدہ کیس نہ تو benchmark ہے اور نہ ہی یہ ثبوت کہ Codex کی دوسری ناکامیوں کی بھی یہی وجہ ہے۔ صرف ایک غیر معمولی جواب بھی ذمہ دار intermediary کی شناخت نہیں کر سکتا اور نہ ہی خاص طور پر DNS cache poisoning کو ثابت کر سکتا ہے۔

ترتیب تبدیل کرنے سے پہلے تشخیص کریں

connection لاگ چیک کریں

غلطی میں موجود اصل hostname تلاش کریں، جس میں chatgpt.com یا openai.com شامل ہیں۔ ناکامی کے وقت matched rule، connection chain، اور غلطی ریکارڈ کریں۔ ایسی connection جسے پراکسی استعمال کرنی چاہیے لیکن DIRECT منتخب کرے، rule-order کے جائزے کا تقاضا کرتی ہے۔ Mihomo routing rules کو اوپر سے نیچے تک جانچتا ہے۔ روٹنگ دستاویزات

اگر کوئی matching connection ظاہر نہیں ہوتی، تو پہلے یہ طے کریں کہ آیا وہ client Clash استعمال کرتا ہے۔ براؤزر میں کامیابی اس راستے کو ثابت نہیں کرتی جو ایک علیحدہ process استعمال کرتی ہے۔

resolution paths کا موازنہ کریں

macOS پر، system resolver اور اس کے موجودہ جواب کا معائنہ کریں:

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

ایک encrypted موازنے کے لیے، 7890 کو اپنے Clash HTTP/mixed port سے بدلیں:

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 کے DNS JSON interface استعمال کرتی ہے۔ connection panel چیک کریں: ایک واضح local proxy Clash میں داخلہ یقینی بناتی ہے، لیکن حتمی egress کا تعین پھر بھی Clash rules ہی کرتے ہیں۔

صرف مختلف IP addresses مداخلت کا ثبوت نہیں ہیں۔ CDN selection، caching، address families، اور Fake-IP اختلافات کی وضاحت کر سکتے ہیں۔ Clash کی Fake-IP range سے کوئی synthetic address بذاتِ خود مشتبہ نہیں ہوتا۔ غیر معمولی جواب کو غلط route اور ناکامی کے ساتھ مربوط کریں، پھر ایک دوسرے تصدیق شدہ network path کے مقابلے میں موازنہ کریں۔ TUN فعال ہونے پر، حتیٰ کہ dig @resolver بھی intercept ہو سکتا ہے؛ یہ خود بخود ایک آزاد upstream test نہیں ہوتا۔

ایک ہدفی Clash Verge Rev بہتری لاگو کریں

اس template کے لیے Mihomo کے ساتھ Clash Verge Rev، ایک موجودہ subscription، اور ایک کام کرنے والا پراکسی node درکار ہے۔ یہ ایک subscription Script ہے، مکمل standalone profile نہیں۔ پہلے موجودہ configuration کا بیک اپ لیں۔ اگر آپ پہلے ہی کوئی script استعمال کرتے ہیں، تو تبدیلی کو اس کی موجودہ main(config) function میں ضم کریں۔ تمام enhancement مراحل کے بعد حتمی runtime configuration کا معائنہ کریں۔ Clash Verge Rev Script دستاویزات

CODEX_PROXY_GROUP کو کسی موجودہ گروپ پر سیٹ کریں اور اس گروپ میں ایک کام کرنے والا پراکسی نوڈ منتخب کریں۔ NODE_DNS کو ایسے DoH ریزولوَر پر سیٹ کریں جو پراکسی کے جڑنے سے پہلے کام کرتا ہو اور نوڈ کے ہوسٹ نیم درست طور پر ریزولو کرے۔ AliDNS کی مثال مین لینڈ-چین کے نیٹ ورک پر توثیق کے لیے دی گئی ہے؛ جہاں یہ مناسب نہ ہو وہاں اسے بدل دیں۔ اسے نیچے دیے گئے 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 پالیسی شامل کرتا ہے اور دیگر قواعد اور ڈومین پالیسیوں کو برقرار رکھتے ہوئے پراکسی قواعد کو ابتدا میں شامل کرتا ہے۔ یہ نوڈ-ہوسٹ نیم ریزولوشن کو تبدیل کرتا ہے۔ یہ چار ڈومین سفکس ابتدائی دائرہ کار ہیں، Codex کی ہر خصوصیت، کسٹم فراہم کنندہ، MCP سروس، یا ٹاسک ڈاؤن لوڈ کی مکمل فہرست نہیں۔

Mihomo ڈومین-مخصوص nameserver-policy اور DNS سرور پتے پر ایک واضح پراکسی سفکس کی حمایت کرتا ہے۔ سرکولر انحصار سے بچنے کے لیے نوڈ ریزولوشن کو ایک آزاد راستہ درکار ہوتا ہے۔ DNS تشکیلِ ترتیب حوالہ

یہ ہدفی اسکرپٹ موجودہ fallback ترتیبات کو برقرار رکھتا ہے۔ انہیں تبدیل کرنے سے پہلے وسیع تر DNS انحصارات کا الگ سے جائزہ لیں۔ پرانی hosts میپنگز یا متصادم، زیادہ-مخصوص پالیسیوں کو بھی چیک کریں۔

TUN کو الگ سے چیک کریں

جو پراسیس سسٹم پراکسی استعمال نہیں کرتے، ان کے لیے Clash Verge Rev میں TUN فعال کریں اور تصدیق کریں کہ یہ چل رہا ہے۔ درج ذیل فیلڈز کو اپنے موجودہ TUN آبجیکٹ میں ضم کریں، اس کی دوسری ترتیبات کو برقرار رکھتے ہوئے:

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

یہ پورٹ 53 پر UDP اور TCP DNS دونوں کا احاطہ کرتے ہیں۔ Mihomo macOS اور Windows پر LAN-سمت DNS کے لیے حدود دستاویز کرتا ہے؛ ایپلی کیشن کے زیرِ انتظام مرموز DNS بھی ان پورٹ-53 قواعد سے باہر ہے۔ یہ فرض کرنے کے بجائے کہ ٹوگل ہر درخواست کا احاطہ کرتا ہے، ریزولوَر اور انٹرفیس کے رویّے کی توثیق کریں۔ TUN حوالہ

تشکیلِ ترتیب، روٹنگ، اور Codex کو الگ الگ جانچیں

پہلے حتمی تشکیلِ ترتیب میں غلطیوں، گروپ حوالہ جات، اور قواعد کی ترتیب کو چیک کریں۔ اگر Mihomo CLI دستیاب ہو، تو mihomo -t -f <final-config-path> یہ جانچتا ہے کہ تشکیلِ ترتیب پارس ہوتی ہے یا نہیں۔ یہ کنیکٹیویٹی ثابت نہیں کرتا۔

اس کے بعد اصل کنکشن روٹنگ کا معائنہ کریں اور اپنے حقیقی مقامی پورٹ کے ذریعے سرٹیفکیٹ-تصدیق شدہ HTTPS پروب چلائیں:

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 درخواست کام کرتی ہے، اور سرٹیفکیٹ توثیق کو غیر فعال کرنا اس جانچ کو غیر مؤثر کر دے گا۔

آخر میں، اس کلائنٹ میں ایک چھوٹا کام مکمل کریں جو اصل میں ناکام ہوا تھا۔ ایک نصب شدہ، مصدقہ CLI درج ذیل اختیاری جانچ چلا سکتی ہے، جو ایک حقیقی ماڈل درخواست کرتی ہے اور اکاؤنٹ کوٹہ استعمال کرتی ہے:

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 میں بدل دینا کافی ہے؟

ضروری نہیں۔ صرف ریزولوَر کا پتہ مرموز کاری، پراکسی روٹنگ، یا رسائی کو قائم نہیں کرتا۔ ریزولوَر، ٹرانسپورٹ، اور ایگریس کو ایک ساتھ جانچیں۔

Codex اس وقت کیوں ناکام ہوتا ہے جب Clash چل رہا ہو؟

ممکن ہے پراسیس پراکسی کو بائی پاس کر رہا ہو، کسی direct اصول سے میچ ہو رہا ہو، یا ایسے نوڈ DNS پر منحصر ہو جو دستیاب نہیں۔ مسئلہ DNS سے غیر متعلق بھی ہو سکتا ہے۔ ایک ساتھ کئی ترتیبات بدلنے سے پہلے اصل کنکشن تلاش کریں۔

اگر یہ پھر بھی منقطع ہو جائے تو کیا کریں؟

اگر DNS، TLS، اور روٹنگ کام کر رہے ہوں، تو سروس کی حالت، گفتگو کے حجم، کلائنٹ ورژن، نوڈ کنکشن کے استحکام، اور عین error body کی جانچ کریں۔ OpenAI فیڈبیک اور logs کے مقامات دستاویز کرتا ہے؛ شیئر کرنے سے پہلے logs میں رازدارانہ معلومات کا جائزہ لیں۔ خرابی دور کرنا اور logs

میں تبدیلی کو واپس کیسے لاؤں؟

شامل کیا گیا Script غیر فعال کریں اور بیک اپ لیا گیا پروفائل، TUN ترتیبات، اور وہ تمام سسٹم DNS ترتیبات بحال کریں جو آپ نے بدلی تھیں۔ الگ proxy-providers ساخت بعد میں نوڈ سبسکرپشنز کو مقامی DNS اور قواعد سے الگ کر سکتی ہے، لیکن اس ہدفی اصلاح کے لیے یہ ضروری نہیں۔

تنصیب اور امپورٹ کے مراحل کے لیے Clash Verge setup دیکھیں۔ دوسری ناکامیوں کے لیے Clash troubleshooting دیکھیں۔ آپ یہ تشخیصی عمل کسی موجودہ مطابقت رکھنے والی سبسکرپشن کے ساتھ استعمال کر سکتے ہیں؛ DNS کی جانچ کے لیے کوئی دوسری سروس خریدنا پیشگی شرط نہیں ہے۔