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, certificate, এবং egress-এর পার্থক্য
আউটপুট শুরু হয়, তারপর stream বিচ্ছিন্ন হয়ে যায়	দীর্ঘস্থায়ী সংযোগ, network পরিবর্তন, এবং service ত্রুটি
শুধু দীর্ঘ কথোপকথন বা compaction ব্যর্থ হয়	ছোট নতুন একটি কাজের সঙ্গে তুলনা করুন; session এবং server ত্রুটি তদন্ত করুন
HTTP 401, 403, 429, বা 5xx	authentication, policy, limit, বা service ব্যর্থতার জন্য response-এর উৎস এবং body পরীক্ষা করুন

OpenAI service status পরীক্ষা করুন এবং সময় ও client version নথিবদ্ধ করুন। আটকে থাকা chat-এর ক্ষেত্রে, OpenAI pending approval আছে কি না পরীক্ষা করা এবং ছোট, নির্দিষ্ট একটি নতুন chat চেষ্টা করারও পরামর্শ দেয়। Desktop এবং CLI version ভিন্ন হতে পারে। আনুষ্ঠানিক troubleshooting

একটি স্থানীয় ঘটনা: অপ্রত্যাশিত DNS উত্তর DIRECT ট্রিগার করেছিল

Clash Verge Rev এবং Mihomo ব্যবহার করা একটি নথিবদ্ধ macOS তদন্তে, proxy node-গুলোতে পৌঁছানো যাচ্ছিল, কিন্তু chatgpt.com একটি GeoIP/CN rule-এর সঙ্গে মিলে গিয়ে একটি direct connection চেষ্টা করেছিল যা timeout হয়। proxy-এর মাধ্যমে পৌঁছানো 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

এখানে দুটি configuration সমস্যা সমাধান করা দরকার: resolution path এবং routing decision। এই নথিবদ্ধ ঘটনাটি কোনো benchmark নয় এবং অন্য Codex ব্যর্থতারও একই কারণ আছে—এমন প্রমাণও নয়। শুধু একটি অস্বাভাবিক উত্তর দিয়েই দায়ী মধ্যবর্তী উপাদানকে শনাক্ত করা যায় না, বা বিশেষভাবে DNS cache poisoning প্রতিষ্ঠা করা যায় না।

configuration পরিবর্তনের আগে নির্ণয় করুন

সংযোগ log পরীক্ষা করুন

ত্রুটিতে থাকা প্রকৃত hostname খুঁজুন, এর মধ্যে chatgpt.com বা openai.com অন্তর্ভুক্ত। ব্যর্থতার সময় মেলানো rule, connection chain, এবং ত্রুটি নথিবদ্ধ করুন। যে সংযোগে proxy ব্যবহার হওয়ার কথা কিন্তু DIRECT নির্বাচন করে, সেখানে rule-order পর্যালোচনা প্রয়োজন। Mihomo routing rule-গুলো উপর থেকে নিচে মূল্যায়ন করে। Routing documentation

যদি কোনো মেলানো সংযোগ দেখা না যায়, আগে নির্ধারণ করুন ওই client Clash ব্যবহার করছে কি না। ব্রাউজারে সফল হওয়া মানেই আলাদা কোনো process যে path ব্যবহার করছে, তা প্রতিষ্ঠা করে না।

resolution path তুলনা করুন

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’s DNS JSON interface ব্যবহার করে। connection panel পরীক্ষা করুন: একটি স্পষ্ট local proxy Clash-এ প্রবেশ নিশ্চিত করে, কিন্তু চূড়ান্ত egress এখনও Clash rule-গুলোই নির্ধারণ করে।

শুধু IP address ভিন্ন হলেই তা হস্তক্ষেপের প্রমাণ নয়। CDN নির্বাচন, caching, address family, এবং 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, এবং কার্যকর একটি proxy node প্রয়োজন। এটি একটি subscription Script, সম্পূর্ণ স্বতন্ত্র profile নয়। আগে বর্তমান configuration-এর ব্যাকআপ নিন। আপনি যদি ইতিমধ্যে একটি script ব্যবহার করেন, তবে পরিবর্তনটি তার বিদ্যমান main(config) function-এ একীভূত করুন। সব উন্নয়ন ধাপের পরে চূড়ান্ত runtime configuration পরীক্ষা করুন। Clash Verge Rev Script documentation

CODEX_PROXY_GROUP-কে বিদ্যমান একটি গ্রুপে সেট করুন এবং সেই গ্রুপে একটি কার্যকর প্রক্সি নোড নির্বাচন করুন। NODE_DNS-কে এমন একটি DoH resolver-এ সেট করুন যা প্রক্সি সংযুক্ত হওয়ার আগে কাজ করে এবং নোড hostname-গুলো সঠিকভাবে resolve করে। AliDNS উদাহরণটি মূলভূখণ্ড-চীনের নেটওয়ার্কে যাচাইয়ের জন্য দেওয়া হয়েছে; উপযুক্ত না হলে এটি বদলে দিন। নিচের AI domain-গুলো 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;
}

স্ক্রিপ্টটি domain-নির্দিষ্ট DNS policy যোগ করে এবং অন্য নিয়ম ও domain policy বজায় রেখে proxy rule-গুলো শুরুতে যুক্ত করে। এটি নোড-hostname resolution পরিবর্তন করে। এই চারটি domain suffix শুরুর জন্য একটি scope, Codex-এর প্রতিটি feature, custom provider, MCP service, বা task download-এর পূর্ণাঙ্গ তালিকা নয়।

Mihomo domain-নির্দিষ্ট nameserver-policy এবং DNS server address-এ একটি স্পষ্ট proxy suffix সমর্থন করে। বৃত্তাকার নির্ভরতা এড়াতে node resolution-এর জন্য একটি স্বাধীন path দরকার। DNS configuration reference

লক্ষ্যভিত্তিক স্ক্রিপ্টটি বিদ্যমান fallback settings বজায় রাখে। সেগুলো বদলানোর আগে বৃহত্তর DNS নির্ভরতাগুলো আলাদাভাবে পর্যালোচনা করুন। পুরনো hosts mapping বা সংঘর্ষপূর্ণ, আরও-নির্দিষ্ট policy আছে কি না তাও পরীক্ষা করুন।

TUN আলাদাভাবে পরীক্ষা করুন

যে process-গুলো system proxy ব্যবহার করে না, সেগুলোর জন্য Clash Verge Rev-এ TUN চালু করুন এবং এটি চলছে কি না যাচাই করুন। নিচের field-গুলো আপনার বিদ্যমান TUN object-এ মিশিয়ে দিন, অন্য 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-নির্দেশিত DNS-এর সীমাবদ্ধতা নথিভুক্ত করেছে; application-managed encrypted DNS-ও এই port-53 rule-গুলোর বাইরে। toggle চালু করলেই সব request কভার হবে ধরে নেওয়ার বদলে resolver এবং interface-এর আচরণ যাচাই করুন। TUN reference

configuration, routing, এবং Codex আলাদাভাবে যাচাই করুন

প্রথমে চূড়ান্ত configuration-এ error, group reference, এবং 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 বন্ধ করলে এই পরীক্ষা অকার্যকর হয়ে যাবে।

সবশেষে, যে client-এ মূলত ব্যর্থতা ঘটেছিল সেখানে একটি ছোট task সম্পন্ন করুন। ইনস্টল করা এবং 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 layer বা renamed group এখনো কোনো enhancement নষ্ট করতে পারে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

system DNS-কে 8.8.8.8-এ পরিবর্তন করাই কি যথেষ্ট?

অবশ্যই নয়। শুধু একটি resolver address encryption, proxy routing, বা reachability প্রতিষ্ঠা করে না। resolver, transport, এবং egress একসঙ্গে যাচাই করুন।

Clash চলমান থাকলেও Codex কেন ব্যর্থ হয়?

process-টি হয়তো proxy এড়িয়ে যাচ্ছে, direct rule-এর সঙ্গে মিলে যাচ্ছে, অথবা অনুপলব্ধ node DNS-এর ওপর নির্ভর করছে। সমস্যাটি DNS-সম্পর্কিত নাও হতে পারে। একসঙ্গে কয়েকটি setting বদলানোর আগে প্রকৃত connection খুঁজে বের করুন।

তবুও যদি এটি disconnect হয়?

যদি DNS, TLS, এবং routing কাজ করে, তবে service status, conversation size, client version, node connection stability, এবং সঠিক error body পরীক্ষা করুন। OpenAI feedback এবং log location নথিভুক্ত করেছে; শেয়ার করার আগে logs-এ secrets আছে কি না পর্যালোচনা করুন। Troubleshooting and logs

আমি কীভাবে পরিবর্তনটি ফিরিয়ে নেব?

যোগ করা Script নিষ্ক্রিয় করুন এবং ব্যাকআপ রাখা profile, TUN settings, এবং আপনি যে system DNS settings পরিবর্তন করেছিলেন সেগুলো পুনরুদ্ধার করুন। আলাদা proxy-providers architecture পরে node subscription-গুলোকে local DNS এবং rule থেকে বিচ্ছিন্ন করতে পারে, তবে এই লক্ষ্যভিত্তিক সমাধানের জন্য এটি প্রয়োজনীয় নয়।

installation এবং import ধাপগুলোর জন্য Clash Verge setup দেখুন। অন্য ব্যর্থতার জন্য Clash troubleshooting দেখুন। DNS পরীক্ষা করার জন্য আপনি বিদ্যমান কোনো সামঞ্জস্যপূর্ণ subscription-এর সঙ্গে এই diagnostic process ব্যবহার করতে পারেন; আরেকটি service কেনা পূর্বশর্ত নয়।