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, नोड पहुंच-योग्यता, और क्या ट्रैफ़िक Clash में प्रवेश करता है
ChatGPT ब्राउज़र में काम करता है लेकिन Codex विफल होता है	प्रॉक्सी, DNS, प्रमाणपत्रों, और egress में अंतर
आउटपुट शुरू होता है, फिर stream डिस्कनेक्ट हो जाती है	लंबे समय तक रहने वाले कनेक्शन, नेटवर्क परिवर्तन, और सेवा त्रुटियाँ
केवल लंबी बातचीतें या compaction विफल होती है	एक छोटे नए कार्य से तुलना करें; session और server त्रुटियों की जांच करें
HTTP 401, 403, 429, या 5xx	प्रमाणीकरण, नीति, सीमाओं, या सेवा विफलताओं के लिए response origin और body की जांच करें

OpenAI सेवा स्थिति जांचें और समय तथा क्लाइंट संस्करण दर्ज करें। अटकी हुई चैट के लिए, OpenAI लंबित अनुमोदनों की जांच करने और एक छोटी, केंद्रित नई चैट आज़माने की भी सिफारिश करता है। Desktop और CLI संस्करण अलग हो सकते हैं। आधिकारिक समस्या-निवारण

एक स्थानीय मामला: एक अप्रत्याशित DNS उत्तर ने DIRECT ट्रिगर किया

Clash Verge Rev और Mihomo का उपयोग करते हुए एक दर्ज macOS जांच में, प्रॉक्सी नोड पहुंच योग्य थे, लेकिन chatgpt.com एक GeoIP/CN नियम से मेल खाता था और उसने 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। यह दर्ज मामला कोई बेंचमार्क या प्रमाण नहीं है कि Codex की अन्य विफलताओं का कारण भी यही है। केवल एक असामान्य उत्तर भी जिम्मेदार मध्यस्थ की पहचान नहीं कर सकता या विशेष रूप से DNS cache poisoning स्थापित नहीं कर सकता।

कॉन्फ़िगरेशन बदलने से पहले निदान करें

कनेक्शन लॉग जांचें

त्रुटि में वास्तविक hostname खोजें, जिसमें chatgpt.com या openai.com शामिल हों। विफलता के समय मेल खाया नियम, connection chain, और त्रुटि दर्ज करें। ऐसा कनेक्शन जिसे प्रॉक्सी का उपयोग करना चाहिए लेकिन DIRECT चुनता है, नियम-क्रम की समीक्षा की मांग करता है। Mihomo routing rules का मूल्यांकन ऊपर से नीचे करता है। रूटिंग प्रलेखन

यदि कोई मेल खाता कनेक्शन दिखाई नहीं देता, तो पहले स्थापित करें कि वह क्लाइंट Clash का उपयोग करता है या नहीं। ब्राउज़र की सफलता किसी अलग process द्वारा उपयोग किए गए path को स्थापित नहीं करती।

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 का उपयोग करता है। कनेक्शन पैनल जांचें: एक स्पष्ट local proxy Clash में प्रवेश की गारंटी देता है, लेकिन अंतिम egress अभी भी Clash rules निर्धारित करते हैं।

केवल अलग IP पते हस्तक्षेप का प्रमाण नहीं हैं। CDN चयन, caching, address families, और Fake-IP अंतर समझा सकते हैं। Clash की Fake-IP range से मिला कोई synthetic address अपने-आप में संदिग्ध नहीं है। एक असामान्य उत्तर को गलत route और विफलता के साथ सहसंबद्ध करें, फिर किसी अन्य सत्यापित network path से तुलना करें। TUN सक्षम होने पर, यहाँ तक कि dig @resolver भी अवरोधित किया जा सकता है; यह स्वतः एक स्वतंत्र upstream test नहीं होता।

लक्षित Clash Verge Rev सुधार लागू करें

इस टेम्पलेट के लिए Mihomo सहित Clash Verge Rev, एक मौजूदा subscription, और एक कार्यशील प्रॉक्सी नोड आवश्यक है। यह एक subscription Script है, पूर्ण standalone profile नहीं। पहले वर्तमान कॉन्फ़िगरेशन का बैकअप लें। यदि आप पहले से कोई script उपयोग करते हैं, तो परिवर्तन को उसके मौजूदा main(config) function में एकीकृत करें। सभी सुधार चरणों के बाद अंतिम runtime configuration की जांच करें। Clash Verge Rev Script प्रलेखन

CODEX_PROXY_GROUP को किसी मौजूदा समूह पर सेट करें और उस समूह में एक काम करने वाला प्रॉक्सी नोड चुनें। NODE_DNS को ऐसे DoH resolver पर सेट करें जो प्रॉक्सी के कनेक्ट होने से पहले काम करे और नोड hostnames को सही ढंग से resolve करे। AliDNS का उदाहरण मुख्यभूमि-चीन नेटवर्क पर सत्यापन के लिए है; जहाँ उपयुक्त न हो, वहाँ इसे बदल दें। इसका उपयोग नीचे दिए गए AI domains को 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;
}

यह script domain-विशिष्ट DNS नीति जोड़ता है और अन्य rules तथा domain policies को बनाए रखते हुए प्रॉक्सी rules को सबसे आगे जोड़ता है। यह node-hostname resolution को बदलता है। ये चार domain suffixes शुरुआती दायरा हैं, Codex की हर सुविधा, custom provider, MCP सेवा, या task download की पूर्ण सूची नहीं।

Mihomo domain-विशिष्ट nameserver-policy और DNS server address पर एक स्पष्ट proxy suffix का समर्थन करता है। circular dependency से बचने के लिए node resolution को एक स्वतंत्र path चाहिए। DNS configuration reference

लक्षित script मौजूदा fallback settings को बनाए रखता है। उन्हें बदलने से पहले व्यापक DNS dependencies की अलग से समीक्षा करें। पुराने hosts mappings या टकराने वाली, अधिक-विशिष्ट policies की भी जाँच करें।

TUN की अलग से जाँच करें

जो processes system proxy का उपयोग नहीं करते, उनके लिए Clash Verge Rev में TUN सक्षम करें और सत्यापित करें कि वह चल रहा है। अपने मौजूदा TUN object में निम्नलिखित fields को मिलाएँ, उसकी अन्य settings को यथावत रखते हुए:

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

ये port 53 पर UDP और TCP DNS को कवर करते हैं। Mihomo, macOS और Windows पर LAN-directed DNS के लिए सीमाओं का दस्तावेज़ देता है; application-managed encrypted DNS भी इन port-53 rules के दायरे से बाहर है। यह मान लेने के बजाय कि toggle हर request को कवर करता है, resolver और interface के व्यवहार को सत्यापित करें। TUN reference

configuration, routing, और Codex को अलग-अलग सत्यापित करें

पहले अंतिम configuration में errors, group references, और rule order की जाँच करें। यदि Mihomo CLI उपलब्ध है, तो mihomo -t -f <final-config-path> यह जाँचता है कि configuration parse होती है या नहीं। यह connectivity सिद्ध नहीं करता।

इसके बाद वास्तविक connection routing की जाँच करें और अपने वास्तविक local port के माध्यम से certificate-verified HTTPS probe चलाएँ:

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 verification के बाद इच्छित service से मिला response इस probe के लिए एक HTTP exchange स्थापित करता है। 401 या 403 फिर भी access को रोक सकते हैं। यह सिद्ध नहीं करता कि authenticated Codex request काम करती है, और certificate verification को disable करना इस जाँच को अमान्य कर देगा।

अंत में, उस client में एक छोटा task पूरा करें जो पहले विफल हुआ था। एक installed, authenticated CLI निम्नलिखित वैकल्पिक जाँच चला सकती है, जो वास्तविक model request करती है और account quota का उपयोग करती है:

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

CLI में सफलता केवल उसी CLI request को सत्यापित करती है; यदि विफलता desktop app में हुई थी, तो उसकी अलग से जाँच करें। subscription update, network change, और sleep/wake के बाद फिर से जाँच करें। बाद की configuration layers या बदले गए group names अब भी किसी enhancement को तोड़ सकते हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या system DNS को 8.8.8.8 पर बदलना पर्याप्त है?

ज़रूरी नहीं। केवल resolver address encryption, proxy routing, या reachability स्थापित नहीं करता। resolver, transport, और egress को साथ में सत्यापित करें।

Codex विफल क्यों होता है जबकि Clash चल रहा है?

process संभव है कि proxy को bypass कर रही हो, किसी direct rule से match कर रही हो, या अनुपलब्ध node DNS पर निर्भर हो। समस्या DNS से असंबंधित भी हो सकती है। एक साथ कई settings बदलने से पहले वास्तविक connection का पता लगाएँ।

यदि यह अब भी disconnect होता है तो क्या करें?

यदि DNS, TLS, और routing काम कर रहे हैं, तो service status, conversation size, client version, node connection stability, और exact error body की जाँच करें। OpenAI feedback और logs locations का दस्तावेज़ देता है; साझा करने से पहले logs में secrets की समीक्षा करें। Troubleshooting and logs

मैं इस बदलाव को वापस कैसे करूँ?

जोड़ी गई Script को disable करें और backup किया गया profile, TUN settings, तथा बदली गई किसी भी system DNS settings को restore करें। अलग proxy-providers architecture बाद में node subscriptions को local DNS और rules से अलग कर सकता है, लेकिन इस लक्षित fix के लिए यह आवश्यक नहीं है।

installation और import steps के लिए Clash Verge setup देखें। अन्य failures के लिए Clash troubleshooting देखें। आप इस diagnostic process का उपयोग किसी मौजूदा compatible subscription के साथ कर सकते हैं; DNS की जाँच के लिए कोई दूसरी service खरीदना पूर्वशर्त नहीं है।