English · فهرست

deyroute status                  # تانل UP است؟ Node آنلاین است؟
deyroute doctor                  # ۱۵ بررسی خودکار + فایل پشتیبانی
deyroute port check 443          # چک چهارمرحله‌ای پورت
deyroute logs main -f            # لاگ زنده تانل، سمت Hub و Node
deyroute events --tunnel main    # در ۲۴ ساعت اخیر چه اتفاقی افتاده

همین ابزارها در منو زیر 6) Diagnostics هستند: 1) Port check، 2) Tunnel test، 3) Speed test، 4) Logs، 5) Doctor.

هر خطا یک کد ثابت به شکل DEY-<حرف><سه رقم> دارد و در منو و خط فرمان یکسان نمایش داده می‌شود:

✖ DEY-P012  Port 443/tcp is already in use
  Why:  nginx (pid 1234) is listening on 0.0.0.0:443
  Fix:  choose another port, or stop that service first
  Log:  /var/log/deyroute/hub.log (search DEY-P012)

خط اول می‌گوید چه شد، Why می‌گوید چرا، Fix می‌گوید چه کنید و Log می‌گوید کجا بیشتر بخوانید. خط‌هایی که زیرش با | شروع می‌شوند جزئیات هستند (مثلاً چند خط آخر لاگ یک بک‌اند). وقتی کمک می‌خواهید، کل این چند خط را کپی کنید و بفرستید. فهرست کامل کدها با Why و Fix در ERRORS.md است.

کد خروج دستورها: 0 موفق، 1 خطای کاربر، 2 خطای سیستم (DEY-X…)، 3 تأیید لازم است (وقتی بدون ترمینال اجرا می‌کنید --yes بدهید).

deyroute doctor                   # همین سرور
deyroute doctor --node de-1       # این Hub به‌علاوه Node de-1
deyroute doctor --out /tmp/doctor.tar.gz

doctor این‌ها را جمع می‌کند: سیستم و نسخه‌ها، وضعیت همه سرویس‌ها، خط‌های آخر همه لاگ‌ها، پورت‌ها و نتیجه چک چهارمرحله‌ای همه Port mapها (هشت‌تا هم‌زمان؛ Port mapی که بعد از دو دقیقه چکش شروع نشده باشد «چک نشده» نوشته می‌شود)، جدول فایروال، تنظیمات کرنل، Nodeها و تأخیر کنترل، پروب نردبان، رویدادهای اخیر و انقضای گواهی‌ها. بعد ۱۵ بررسی خودکار انجام می‌دهد و یک خلاصه کوتاه به زبان ساده چاپ می‌کند (رنگی فقط در ترمینال؛ اگر خروجی به فایل یا برنامه دیگری برود متن ساده است)، مثلاً:

• Node de-1 is offline on the control channel, but tunnel main still passes traffic: the control network has a problem, the tunnel is healthy — یعنی فقط کانال کنترل مشکل دارد و تانل سالم است.
• Tunnel main is DOWN and every transport failed or is quarantined: the IP of node de-1 is probably blocked — یعنی احتمالاً IP سرور Node بلاک شده.
• Tunnel main is connected, but the service behind it on node de-1 does not answer on 127.0.0.1:443 — یعنی تانل وصل است ولی سرویس پشتش روی Node جواب نمی‌دهد.
• Clock of de-1 differs from the hub by …: TLS connections fail with a large difference — یعنی ساعت سرورها با هم فرق دارد.

کنار هر مورد یک خط Fix: هست. کرنلی که BBR ندارد، یا tuning.bbr: false، مشکل حساب نمی‌شود: پروفایل کرنل بدون BBR اعمال می‌شود (با هشدار) و اعمال دوباره‌اش چیزی را عوض نمی‌کند. توکن Joinی که با --ttl بیشتر از ۱۵ دقیقه ساخته شده با زمان انقضایش گزارش می‌شود (info)، چون تا آن موقع پورت کنترل از هر آدرسی اتصال می‌پذیرد؛ توکن‌های منقضی خودکار پاک می‌شوند. doctor یک فایل پشتیبانی هم می‌نویسد: /root/deyroute-doctor-<UTC>.tar.gz که همه رازها از آن حذف شده‌اند (توکن‌ها، کلیدها و رمزها پوشانده می‌شوند و فایل قبل از نوشته شدن یک بار دیگر بررسی می‌شود). این فایل را همراه خلاصه بفرستید. اگر سرویس اجرا نباشد، doctor باز هم هر چه روی همین سرور بتواند جمع می‌کند و این را اعلام می‌کند.

deyroute logs main -f            # تانل: خط‌های Hub و Node با پیشوند [hub] / [node]
deyroute logs hub --since 1h
deyroute logs node               # روی Node: سرویس خودش
deyroute events --since 24h --json

لاگ‌های خود deyroute به شکل JSON خط‌به‌خط با زمان UTC هستند؛ لاگ‌ها (و لاگ هر تانل در /var/log/deyroute/tunnels/) در ۲۰ مگابایت چرخانده می‌شوند و ۵ فایل فشرده نگه داشته می‌شود. منو (6) Diagnostics ← 4) Logs) چنین خطی را با زمان محلی به شکل 12:41:03 WARN failover probe failed tunnel=main code=DEY-F001 نشان می‌دهد و جلوی خط‌های لاگ یک تانل [hub] یا [node] می‌گذارد. برای جزئیات بیشتر یک دستور را با --debug اجرا کنید یا سرویس را با DEYROUTE_DEBUG=1 روشن کنید. رازها هیچ‌وقت در لاگ نمی‌آیند (به شکل *** چاپ می‌شوند).

رویدادهای مهم: tunnel_up، tunnel_degraded، tunnel_down، switch_transport، switch_node، failback، failback_failed، flapping، node_online، node_offline، node_ip_changed، service_down، backend_crash، probe_error، rung_skipped، rung_restored، config_applied. سوییچ دستی با نام switch_transport یا switch_node و دلیل manual switch to … ثبت می‌شود. بخش LAST EVENTS داشبورد (و deyroute status) هر نوع رویداد را با یک کلمه کوتاه نشان می‌دهد: switch، down، node offline، rung skipped، rolled back.

سرویسی که منو و دستورها با آن کار می‌کنند روشن نیست.

systemctl status deyroute-hub        # روی Node: deyroute-node
systemctl start deyroute-hub
journalctl -u deyroute-hub -n 50

اگر سرور اصلاً راه‌اندازی نشده باشد، خط Fix همین را می‌گوید: deyroute setup را بزنید یا به یک Hub وصل شوید.

✖ DEY-P012  Port 443/tcp is already in use
  Why:  nginx (pid 1234) is listening on 0.0.0.0:443

برنامه دیگری روی Hub این پورت را گرفته. یا پورت دیگری انتخاب کنید (deyroute port suggest) یا آن برنامه را خودتان متوقف کنید (systemctl stop nginx; systemctl disable nginx). DEYROUTE هیچ‌وقت برنامه‌ای را که مال خودش نیست متوقف نمی‌کند. DEY-P011 یعنی پورت رزرو است (22، پورت کنترل، 30000 تا 31999).

deyroute port check 443 نشان می‌دهد کدام فایروال پورت را بسته و دستور دقیق باز کردنش را می‌دهد (مثلاً ufw allow 443/tcp). آن را خودتان اجرا کنید، یا بگذارید deyroute اجرایش کند: deyroute port check 443 --open (یا در منو 4) Ports ← Check port ← 1) Open it in the firewall) دستور را نشان می‌دهد و فقط بعد از اینکه yes را تایپ کنید روی Hub اجرا می‌کند. deyroute اول فایروال را دوباره چک می‌کند و فقط دستوری را اجرا می‌کند که خودش از روی فایروال پیداشده و شماره پورت می‌سازد؛ اگر این دستور دیگر همانی نباشد که تأیید کردید (فایروال در این فاصله عوض شده)، هیچ چیزی اجرا نمی‌شود (DEY-P032): پورت را دوباره چک کنید. DEY-P033 یعنی دستور شکست خورد یا پورت را باز نکرد (یک قانون قبلی در همان فایروال آن را رد می‌کند)؛ خروجی دستور زیر خطا نشان داده می‌شود. DEY-P014 (از Node در دسترس نیست؛ زیر چهار مرحله چک پورت، همراه خطای اتصال Node چاپ می‌شود) معمولاً یعنی فایروال پنل ارائه‌دهنده سرور پورت را بسته: آنجا بازش کنید. deyroute security firewall show را هم ببینید. DEY-P031 یعنی DEYROUTE روی این Hub فایروال را مدیریت نمی‌کند (security.firewall_managed: false) و باید پورت‌ها را دستی باز کنید.

تست UDP بین Hub و Node شکست خورده، پس ترنسپورت‌هایی که UDP لازم دارند (hysteria2/udp، wireguard/kernel، backhaul/udp، frp/quic، frp/kcp) برای این Node کنار گذاشته می‌شوند. ترنسپورت‌های TCP کار می‌کنند و لازم نیست کاری بکنید. اگر آن‌ها را می‌خواهید، UDP را بین دو سرور باز کنید (فایروال پنل سرور)؛ پله‌های کنارگذاشته هر ۳۰ دقیقه دوباره تست می‌شوند. deyroute node test de-1 نتیجه را به شکل UDP ok یا blocked نشان می‌دهد. تا وقتی این تست هنوز اجرا نشده (Node از زمان join آفلاین بوده) هم این پله‌ها کنار گذاشته می‌شوند: دلیلشان has not run yet است و وقتی Node آنلاین شد و تست پاس شد برمی‌گردند. پاس شدن تست فقط نشان می‌دهد که دیتاگرام‌های ساده رد می‌شوند، نه اینکه یک پروتکل VPN مثل WireGuard هم رد می‌شود (پرسش‌های فیلترینگ، بخش «پله skip‌شده یعنی چه؟»).

• اگر تانل هنوز ترافیک را رد می‌کند، فقط کانال کنترل قطع است: تانل سالم است و سوییچی انجام نمی‌شود.
• روی Node: systemctl status deyroute-node و deyroute logs node.
• Node باید به HUB_IP:44433 برسد؛ فایروال پنل سرور ایران را چک کنید.
• اگر سرور Node خاموش است یا IP آن بلاک شده، تانل به Node پشتیبان می‌رود — اگر ندارید، اضافه کنید (Node پشتیبان).
• DEY-N004: نسخه‌ها فرق دارند؛ صفحه Join بخش «نسخه ناسازگار».

همه ترنسپورت‌ها روی همه Nodeها شکست خورده‌اند. نردبان هر ۳۰ ثانیه (کم‌کم تا هر ۵ دقیقه) از پله ۱ دوباره امتحان می‌شود. این‌ها را چک کنید:

۱. deyroute node test de-1 — اصلاً به Node دسترسی هست؟

۲. deyroute tunnel show main — کدام پله‌ها skip یا قرنطینه شده‌اند؟

۳. deyroute logs main — خطاهای بک‌اندها.

۴. سرویس روی Node روشن است؟ (DEY-F005)

اگر همه پله‌ها timeout می‌شوند، احتمالاً IP سرور Node از سمت Hub بلاک شده: به Node یک IP جدید بدهید یا یک Node پشتیبان اضافه کنید.

تانل کار می‌کند ولی پشتش روی Node چیزی جواب نمی‌دهد (مثلاً Xray متوقف شده یا روی پورت دیگری گوش می‌دهد). سرویس را روشن کنید (systemctl restart xray) و مطمئن شوید روی مقصد تانل گوش می‌دهد (پیش‌فرض 127.0.0.1:443). اگر Node پشتیبان داشته باشید، تانل در این مدت به آن می‌رود.

• بررسی‌های تانل فقط از روی Hub و Node انجام می‌شوند و فیلترینگ داخل ایران را نمی‌بینند. اگر کاربران به HUB_IP:443 نمی‌رسند، ممکن است IP یا پورت Hub برایشان فیلتر شده باشد: پورت دیگری امتحان کنید (مثلاً 2053 یا 8443) یا Hub را جابه‌جا کنید (جابه‌جایی Hub).
• کانفیگ کلاینت را چک کنید: فقط آدرس به IP سرور ایران عوض می‌شود؛ پورت، UUID، SNI، host و path همان تنظیمات Node می‌مانند.
• deyroute diag probe main --all-ports همه پورت‌های تانل را پروب می‌کند.

بعد از ۶ سوییچ خودکار در یک ساعت، Failover وضعیت فعلی را نگه می‌دارد. شبکه ناپایدار است: deyroute events --tunnel main را بخوانید، یک ترنسپورت را ثابت کنید (deyroute tunnel switch main --transport <id>) یا Failover را موقتاً متوقف کنید (deyroute tunnel pause main).

DEY-B003 خط‌های آخر لاگ بک‌اند را نشان می‌دهد؛ DEY-B004 یعنی روشن شده ولی در مهلت ۱۵ ثانیه ترافیکی از تانل رد نشده. deyroute logs main را بخوانید، بعد deyroute tunnel restart main بزنید یا به پله دیگری سوییچ کنید. DEY-B001: باینری دانلود نشد — یک Node باید آنلاین باشد (Hub از طریق آن دانلود می‌کند)، یا DEYROUTE_MIRROR را تنظیم کنید.

deyroute tunnel test-ladder پله‌ای را که اولین پروبش را پاس کرده در تمام ۲۰ ثانیه‌اش روشن نگه می‌دارد. DEY-B073 یعنی یکی از پروب‌های بعدی شکست خورد: وقتی پله بالا آمد ترافیک رد می‌شد و چند ثانیه بعد قطع شد. فیلترینگی که تانل تازه را راه می‌دهد و بعد قطعش می‌کند همین شکل را دارد. به تانل نردبانی بدهید که این پله در آن پایین‌تر باشد یا اصلاً نباشد، چه به شکل فهرست درون‌خطی (deyroute tunnel edit main --ladder a,b,c) چه با deyroute ladder create، و test-ladder را دوباره اجرا کنید. ثانیه‌های داخل پیام از شروع پنجره پروب آن پله شمرده می‌شوند. جدول فقط کد و پیام را نشان می‌دهد؛ deyroute tunnel test-ladder main --yes --json خطای پروب را هم می‌دهد، در error.detail نتیجه همان پله.

هیچ‌کدام از decoyهای پله‌های Reality از Hub جواب ندادند. رویداد دلیل هر کدام را می‌گوید. بررسی با خانواده آدرس hub.public_ip وصل می‌شود (اگر IPv4 باشد، با IPv4)، پس decoy باید از Hub با همان خانواده جواب بدهد. دلیلی مثل www.example.com: resolves to a private address from the hub (10.0.0.1; DNS tampering?) یعنی resolver سرور Hub برای این نام فقط آدرس خصوصی یا رزرو برگردانده است: احتمالاً DNS آن دستکاری شده. decoyهای دیگری انتخاب کنید (پرسش‌های فیلترینگ)، یا Hub را به resolverی وصل کنید که دستکاری نشده باشد (/etc/resolv.conf) و با dig +short www.example.com بررسی کنید.

اتصال کنترل یک Node از IPv4 به IPv6 رفته است (معمولاً بعد از deyroute node set-hub با آدرس IPv6 سرور Hub). وقتی deyroute فایروال Hub را مدیریت می‌کند، رویداد و hub.log (فیلد hint=) آن را توضیح می‌دهند و دستور برگشت را در اوایل متن نام می‌برند، مثلاً deyroute node set-hub 5.6.7.8:44433: آن را روی Node اجرا کنید. تا آن موقع فایروال Hub ترنسپورت‌هایی را که در آن‌ها Node به Hub وصل می‌شود دور می‌اندازد. IPv6 بین Hub و Node پشتیبانی نمی‌شود؛ صفحه Join را ببینید.

deyroute optimize check مقداری در کرنل پیدا کرده که دیگر همانی نیست که deyroute گذاشته بود. جدول نشان می‌دهد چه کسی عوضش کرده: فایلی که در یکی از پوشه‌های sysctl.d بعد از 99-deyroute.conf می‌آید، /etc/sysctl.conf (آخر از همه اعمال می‌شود و بر همهٔ فایل‌های sysctl.d غلبه می‌کند)، یا نوشتن در حال کار توسط یک ابزار دیگر. آن تنظیم را بردارید یا عمداً نگهش دارید؛ deyroute optimize auto مقدار deyroute را دوباره فهرست و اعمال می‌کند. Hub همین بررسی را هر ۶ ساعت انجام می‌دهد و یک رویداد هشدار ثبت می‌کند؛ هیچ‌وقت خودش مقداری را عوض نمی‌کند. تنظیم خودکار را ببینید.

لاگ کرنل می‌گوید nf_conntrack: table full, dropping packet و اتصال‌های جدید وصل نمی‌شوند، یا deyroute optimize check می‌گوید جدول بیش از ۸۰٪ پر است. deyroute optimize auto را اجرا کنید: جدول را به اندازهٔ RAM سرور می‌کند (۶۴ ورودی به ازای هر MiB، دست‌کم 65536) و مدت ماندن ورودی‌های کاربرانی را که رفته‌اند کوتاه می‌کند (یک روز به جای پنج روز). اگر خودتان مقدار بیشتری گذاشته باشید همان می‌ماند. در کانتینر (DEY-X064) جدول مال میزبان است: از ارائه‌دهنده بخواهید. تنظیم خودکار را ببینید.

اگر ساعت یک سرور خیلی جلو یا عقب باشد، TLS خطا می‌دهد. همگام‌سازی ساعت را روی هر دو سرور روشن کنید: timedatectl set-ntp true.