Codex ממשיך להתחבר מחדש? בדקו DNS וניתוב Clash

שגיאות ב-Codex כמו Reconnecting...,‏ stream disconnected before completion ו-error sending request עשויות להיות קשורות להפרעות ב-DNS או לניתוב שגוי ב-Clash. מדריך זה מסביר כיצד לבדוק את האפשרות הזו, להחיל שיפור ממוקד עבור Clash Verge Rev, ולאמת את התוצאה.

מה באמת מראים הדיווחים מהקהילה

משתמשי Reddit דיווחו על משימות שנקטעו בעת פנייה אל chatgpt.com/backend-api/codex/responses, ניסיונות התחברות מחדש חוזרים, ושגיאות בגוף התגובה. דיווחים אלה מבססים תסמינים, לא אבחנת DNS. בקשה שנקטעה, לולאת התחברות מחדש

דיון נפרד מתאר כשלים במהלך דחיסת הקשר מרוחק. אחד המגיבים מציע לבדוק את הפרוקסי, אך הדיון אינו מבסס סיבה מאומתת. דיון על דחיסה

דיווחים ב-X מציגים שאלות דומות: פוסט מ-9 בספטמבר מתאר כשלים מתמשכים בזרם, בעוד שפוסט מ-6 בספטמבר מדווח על פקיעת זמן המתנה בחוסר פעילות של SSE במהלך דחיסה מרוחקת. אף אחד מהם אינו מספק השוואת DNS. אלו דוגמאות מועילות לבעיות של משתמשים, אך הן אינן מבססות סיבה משותפת. דיווח זרם ב-X, דיווח דחיסה ב-X

תסמין	מה לבדוק
פקיעת זמן מיידית עם שגיאת resolver	DNS, נגישות לצומת, והאם התעבורה נכנסת ל-Clash
ChatGPT עובד בדפדפן אבל Codex נכשל	הבדלים בפרוקסי, DNS, תעודות, ו-egress
הפלט מתחיל ואז הזרם מתנתק	חיבורים ארוכי-חיים, שינויים ברשת, ושגיאות שירות
רק שיחות ארוכות או דחיסה נכשלות	השוו מול משימה חדשה וקטנה; בדקו שגיאות סשן ושרת
HTTP 401, 403, 429, או 5xx	בדקו את מקור התגובה וגופה עבור אימות, מדיניות, מגבלות, או כשלים בשירות

בדקו את מצב השירות של OpenAI ורשמו את השעה ואת גרסת הלקוח. עבור שיחות תקועות, OpenAI ממליצה גם לבדוק אם יש אישורים ממתינים ולנסות שיחה חדשה, קטנה וממוקדת יותר. גרסאות Desktop ו-CLI עשויות להיות שונות. פתרון תקלות רשמי

מקרה מקומי: תשובת DNS בלתי צפויה הפעילה DIRECT

בחקירה מתועדת אחת ב-macOS באמצעות Clash Verge Rev ו-Mihomo, צומתי הפרוקסי היו נגישים, אך chatgpt.com התאים לכלל GeoIP/CN וניסה חיבור ישיר שפג הזמן שלו. השוואה מול DNS מוצפן שהושג דרך הפרוקסי הראתה תשובה חריגה בנתיב הרזולוציה המקומי.

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

יש שתי בעיות תצורה שצריך לטפל בהן: נתיב הרזולוציה והחלטת הניתוב. המקרה המתועד הזה אינו benchmark ואינו הוכחה לכך שלכשלים אחרים ב-Codex יש אותה סיבה. גם תשובה חריגה לבדה אינה יכולה לזהות את גורם הביניים האחראי או לבסס באופן ספציפי הרעלת מטמון DNS.

אבחנו לפני שינוי התצורה

בדקו את יומן החיבורים

חפשו את שם המארח בפועל שמופיע בשגיאה, כולל chatgpt.com או openai.com. רשמו את הכלל שהותאם, את שרשרת החיבור, ואת השגיאה בזמן הכשל. חיבור שאמור להשתמש בפרוקסי אך בוחר DIRECT מצדיק בדיקה של סדר הכללים. Mihomo מעריך כללי ניתוב מלמעלה למטה. תיעוד ניתוב

אם לא מופיע חיבור תואם, קודם קבעו האם אותו לקוח משתמש ב-Clash. הצלחה בדפדפן אינה מבססת את הנתיב שבו משתמש תהליך נפרד.

השוו נתיבי רזולוציה

ב-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'

הבקשה משתמשת ב-ממשק ה-DNS JSON של Cloudflare. בדקו את לוח החיבורים: פרוקסי מקומי מפורש מבטיח כניסה ל-Clash, אך כללי Clash עדיין קובעים את ה-egress הסופי.

כתובות IP שונות לבדן אינן הוכחה להפרעה. בחירת CDN, מטמון, משפחות כתובות, ו-Fake-IP יכולים להסביר הבדלים. כתובת סינתטית מטווח ה-Fake-IP של Clash אינה חשודה מטבעה. קשרו תשובה חריגה לנתיב השגוי ולכשל, ואז השוו מול נתיב רשת מאומת אחר. כאשר TUN מופעל, אפילו dig @resolver עשוי להיות מיורט; הוא אינו אוטומטית בדיקת upstream עצמאית.

החילו שיפור ממוקד עבור Clash Verge Rev

תבנית זו דורשת Clash Verge Rev עם Mihomo, מנוי קיים, וצומת פרוקסי עובד. זהו Script של מנוי, לא פרופיל עצמאי מלא. גבו תחילה את התצורה הנוכחית. אם אתם כבר משתמשים בסקריפט, שלבו את השינוי בתוך הפונקציה הקיימת main(config) שלו. בדקו את תצורת זמן הריצה הסופית לאחר כל שלבי השיפור. תיעוד Script של Clash Verge Rev

הגדרו את CODEX_PROXY_GROUP לקבוצה קיימת ובחרו צומת proxy תקין באותה קבוצה. הגדרו את NODE_DNS לפותר DoH שפועל לפני שה-proxy מתחבר ופותר נכון את שמות המארחים של הצמתים. הדוגמה של 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 ייעודית לדומיינים ומקדים כללי proxy תוך שמירה על כללים ומדיניות דומיינים אחרים. הוא משנה את אופן פתרון שמות המארחים של הצמתים. ארבע סיומות הדומיין הן תחום התחלה, ולא רשימה ממצה של כל תכונה ב-Codex, ספק מותאם אישית, שירות MCP או הורדת משימה.

Mihomo תומך ב-nameserver-policy ייעודי לדומיין ובסיומת proxy מפורשת על כתובת שרת DNS. פתרון צמתים דורש נתיב עצמאי כדי להימנע מתלות מעגלית. עיון בהגדרות DNS

הסקריפט הממוקד שומר על הגדרות fallback קיימות. בדקו בנפרד תלותי DNS רחבים יותר לפני החלפתם. בדקו גם מיפויי hosts מיושנים או מדיניות מתנגשת וספציפית יותר.

בדקו את TUN בנפרד

עבור תהליכים שאינם משתמשים ב-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

תחילה בדקו את ההגדרה הסופית לאיתור שגיאות, הפניות לקבוצות וסדר הכללים. אם ה-CLI של Mihomo זמין, 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 הזו; בדקו את אפליקציית הדסקטופ בנפרד אם שם אירע הכשל. בדקו שוב לאחר עדכון מנוי, שינוי רשת ומצב שינה/התעוררות. שכבות הגדרה מאוחרות יותר או קבוצות ששמן שונה עדיין יכולות לשבור שיפור.

שאלות נפוצות

האם מספיק לשנות את ה-DNS של המערכת ל-8.8.8.8?

לא בהכרח. כתובת של פותר לבדה אינה יוצרת הצפנה, ניתוב דרך proxy או נגישות. אמתו יחד את הפותר, התעבורה והיציאה.

למה Codex נכשל בזמן ש-Clash פועל?

ייתכן שהתהליך עוקף את ה-proxy, מתאים לכלל direct, או תלוי ב-DNS של צומת שאינו זמין. ייתכן גם שהבעיה אינה קשורה ל-DNS. מצאו את החיבור בפועל לפני שמשנים כמה הגדרות בבת אחת.

מה אם הוא עדיין מתנתק?

אם DNS, TLS והניתוב פועלים, חקרו את מצב השירות, גודל השיחה, גרסת הלקוח, יציבות חיבור הצומת וגוף השגיאה המדויק. OpenAI מתעדת מיקומי משוב ולוגים; עברו על הלוגים לאיתור סודות לפני השיתוף. פתרון תקלות ולוגים

איך מבטלים את השינוי?

השביתו את ה-Script שנוסף ושחזרו את הפרופיל המגובה, הגדרות ה-TUN וכל הגדרות DNS מערכת ששיניתם. ארכיטקטורת proxy-providers נפרדת יכולה בהמשך לבודד מנויי צמתים מ-DNS וכללים מקומיים, אך אינה נדרשת לתיקון הממוקד הזה.

לשלבי התקנה וייבוא, ראו הגדרת Clash Verge. לכשלים אחרים, ראו פתרון תקלות ב-Clash. ניתן להשתמש בתהליך האבחון הזה עם מנוי תואם קיים; רכישת שירות אחר אינה תנאי מוקדם לבדיקת DNS.