حل مشکلات

کدام ابزار را استفاده کنید

قبل از نصب           → meridian check IP
  "آیا این سرور برای Meridian کار می‌کند؟"
  آزمایش‌ها: قابلیت رسیدن SNI، درگاه 443، DNS، OS، فضای دیسک.

بعد از نصب، سالم است؟ → meridian check
  "آیا proxy از جایی که من هستم قابل رسیدن است؟"
  آزمایش‌ها: listeners پیکربندی‌شده، TLS/SNI، subscription تحویل‌شده و ترافیک proxy واقعی.
  SSH نیاز نیست — از دستگاه کلاینت اجرا می‌شود.

بعد از نصب، دسترسی را بررسی کنید → meridian test IP --probe
  "آیا این استقرار proxy یا سطح مدیریت را فاش می‌کند؟"
  آزمایش‌ها: درگاه‌های عمومی، رفتار TLS/HTTP، مسیرها، SNI، DNS و سیاست توپولوژی.
  SSH نیاز نیست — از دستگاه کلاینت اجرا می‌شود.

بعد از نصب، چیزی شکسته است → meridian doctor IP
  "همه چیز را برای debugging جمع‌آوری کنید."
  جمع‌آوری: OS سرور، Docker، لاگ‌های گره Remnawave و nginx، درگاه‌ها، firewall، SNI، DNS.

--ai را به check یا doctor برای یک prompt تشخیصی آماده AI اضافه کنید.

نمی‌تواند اصلاً اتصال برقرار کند

درگاه 443 قابل رسیدن نیست

علت‌ها:

1. firewall cloud provider / security group درگاه 443 inbound را مسدود می‌کند
2. ISP یا شبکه کل IP سرور را مسدود می‌کند
3. سرور خاموش است یا proxy اجرا نمی‌شود
4. UFW روی سرور درگاه 443 را اجازه نمی‌دهد

راه‌حل‌ها:

1. کنسول cloud provider را بررسی کنید — مطمئن شوید درگاه 443/TCP inbound مجاز است
2. از شبکه دیگری امتحان کنید (داده تلفن، Wi-Fi دیگر)
3. SSH شوید و بررسی کنید: docker ps (آیا ctlsvc-api و netagent اجرا می‌شوند؟)، systemctl status nginx، ss -tlnp sport = :443
4. UFW را بررسی کنید: ufw status — باید 443/tcp ALLOW نشان دهد

handshake TLS ناموفق

علت‌ها:

1. Xray درون Docker container اجرا نمی‌شود
2. درگاه 443 توسط سرویس دیگری اشغال شده است
3. هدف SNI Reality از سرور قابل رسیدن نیست

راه‌حل‌ها:

1. Xray را بررسی کنید: meridian logs IP -c node -n 20
2. درگاه را بررسی کنید: ss -tlnp sport = :443 — باید nginx باشد
3. SNI را آزمایش کنید: meridian check IP --sni HOST

دامنه قابل رسیدن نیست

علت‌ها:

1. DNS به IP سرور اشاره نمی‌کند
2. nginx اجرا نمی‌شود یا TLS certificate دریافت نکرد
3. nginx مسیریابی SNI domain را درست انجام نمی‌دهد

راه‌حل‌ها:

1. DNS را بررسی کنید: dig +short yourdomain.com @8.8.8.8
2. nginx را بررسی کنید: systemctl status nginx
3. فایل‌های nginx routing را بررسی کنید: ls /etc/nginx/stream.d/ /etc/nginx/sites-enabled/ (فایل‌های Meridian meridian-v4- شروع می‌شوند) و nginx -t

اتصال پس از چند ثانیه قطع می‌شود

علت‌ها:

1. مسائل MTU در مسیر شبکه
2. ISP قطع کردن جلسات TLS طولانی

راه‌حل‌ها:

1. شبکه دیگری امتحان کنید
2. مسیر XHTTP یا WSS استفاده کنید (حالت domain)

Deploy ناموفق

“ترافیک هیچ از طریق آن عبور نمی‌کند”

سرور deploy شد اما ترافیک واقعی از طریق هدف پنهان‌سازی انتخاب‌شده با --sni جریان نیفتاد. هدف دیگری انتخاب کنید — meridian scan IP در شبکه سرور خود موارد را پیدا می‌کند — و دستور deploy را دوباره با --sni جدید اجرا کنید. بدون --sni، Meridian قبلاً www.google.com، dl.google.com و www.cloudflare.com را به ترتیب امتحان می‌کند.

“سرور نمی‌تواند به هدف پنهان‌سازی Reality برسد”

سرور HTTPS outbound کار نمی‌کند به هدف پیش‌فرض. firewall outbound provider را بررسی کنید یا هدف قابل دسترس را با --sni پاس دهید.

Deploy قطع‌شده یا ناموفق

Deploys و applies checkpoint شده‌اند. علت گزارش‌شده را برطرف کنید و دستور یکسان را دوباره اجرا کنید؛ مراحل تمام شده پرش می‌شوند.

تضاد درگاه 443

سرویس دیگر (Apache، Nginx) درگاه 443 را استفاده می‌کند. آن را متوقف کنید یا سرور تمیز استفاده کنید. meridian check IP به شما می‌گوید درگاه را کیست.

نصب Docker ناموفق

بسته‌های Docker متضاد از distro repos. Meridian خود را حذف می‌کند اما Docker قبلاً اجرا می‌شود با containers، پرش می‌کند تا اختلال جلوگیری شود.

rename پنل هنگام upgrade متوقف می‌شود

meridian apply پنلی را که توسط نسخه beta 4.0 deploy شده از /opt/remnawave به /opt/ctlsvc منتقل می‌کند. پیش از stop کردن هر چیزی، اگر هر دو دایرکتوری وجود داشته باشند یا /opt/remnawave یک mount point باشد، ادامه نمی‌دهد. دایرکتوری‌ای را که data/ و .env پنل در آن است به‌عنوان /opt/ctlsvc نگه دارید (یا volume را همان‌جا mount کنید)، دیگری را کنار بگذارید و دوباره meridian apply را اجرا کنید. rename‌ای که وسط کار قطع شده باشد در apply بعدی ادامه پیدا می‌کند.

خطاهای اتصال SSH

SSH دستی را امتحان کنید: ssh root@SERVER_IP. مطمئن شوید دسترسی مبتنی بر کلید داریدید. اگر root نیستید --user flag استفاده کنید. اگر سرور فقط گذرواژه می‌پذیرد، meridian deploy را در یک ترمینال و بدون --yes اجرا کنید تا کلید را نصب کند (ببینید سرورهای فقط با گذرواژه)، یا یک بار ssh-copy-id root@SERVER_IP را اجرا کنید.

Xray در node container شروع نمی‌شود

Container را بررسی کنید: meridian logs IP -c node -n 50. علت‌های معمول تصادم درگاه روی host (node در network_mode: host اجرا می‌شود، بنابراین درگاه‌های cluster.yml باید آزاد باشند)، panel غیرقابل دسترس (ثبت گره نیاز به node_secret_key پنل در boot دارد) یا NET_ADMIN capability گمشده.

راه‌حل: meridian check IP را اجرا کنید و remediation آن را قبل از redeploy دنبال کنید. برای تأیید وضعیت پنل Remnawave، وارد UI مدیریت در https://<IP>/<secret_path>/ شوید و Nodes را بررسی کنید — گره باید connected باشد؛ meridian fleet status همان اطلاعات را از CLI نشان می‌دهد.

فضای دیسک ناکافی

کمتر از 2GB آزاد. فضا خالی کنید: docker system prune -af، journalctl --vacuum-time=1d، /var/log/ را بررسی کنید.

DNS resolution ناموفق (حالت domain)

certificate برای دامنه شما تنها زمانی می‌تواند صادر شود که رکورد A دامنه به سرور اشاره کند (ابر خاکستری در حین deploy). رکورد را به‌روز کنید، برای تکثیر انتظار دهید (معمولاً 5–15 دقیقه)، سپس دستور deploy یکسان را دوباره اجرا کنید. meridian check IP --domain DOMAIN این را قبل از deploy بررسی می‌کند.

کار می‌کرد، اکنون متوقف شد

بیشترین علت معمول: IP سرور مسدود شد. meridian test IP را اجرا کنید؛ یافته‌های آن قابلیت رسیدن شبکه را از TLS، subscription و شکست‌های اجرای proxy تمایز می‌کند. شکست TCP می‌تواند firewall ابر یا سرور آفلاین را نیز به معنی باشد.

راهنمای بازیابی IP مسدود را برای گزینه‌های بازیابی (خروجی جایگزین، relay، fallback CDN) ببینید.

علت‌های دیگر:

• سرور reboot شد و سرویس‌ها شروع نشدند → meridian plan نشان می‌دهد چه چیز خاموش است و meridian apply تعمیر می‌کند. دستی: docker compose up -d در /opt/ctlsvc و /opt/netagent، سپس systemctl restart nginx
• دیسک پر — df -h /، docker system prune -af

سرعت کم

1. سرور جغرافیایی نزدیک‌تر انتخاب کنید (فنلاند، هلند، سوئد برای اروپا/خاورمیانه)
2. بار سرور را بررسی کنید: htop یا uptime
3. مسیر XHTTP یا WSS را امتحان کنید (حالت domain) — مسیریابی از طریق Cloudflare گاهی بهتر است
4. تأیید BBR فعال است: sysctl net.ipv4.tcp_congestion_control

هرگز پروتکل‌های دیگر (OpenVPN, WireGuard) را روی سرور یکسان اجرا نکنید — IP را flag می‌کند.

کمک امکان‌پذیر شده توسط AI

meridian doctor --ai

یک prompt تشخیصی را به clipboard کپی می‌کند برای استفاده با هر دستیار AI.

یا تشخیص جمع‌آوری کنید برای GitHub issue:

meridian doctor

relay کار نمی‌کند

بخش راهنمای Relay — حل مشکلات را برای مسائل خاص relay (تضاد درگاه، firewall، خروجی غیرقابل دسترس، سرویس شروع نشده) ببینید.

تفسیر خروجی preflight

بررسی	آنچه آزمایش می‌کند	اگر ناموفق باشد
قابلیت رسیدن هدف SNI	آیا سرور می‌تواند سایت پنهان‌سازی را بدست آورد؟	outbound سرور محدود است. --sni با SNI مختلف امتحان کنید
دسترسی درگاه 443	آیا درگاه 443 آزاد یا توسط Meridian استفاده می‌شود؟	سرویس دیگر روی 443 است. آن را متوقف کنید یا سرور تمیز استفاده کنید
قابلیت رسیدن خارجی درگاه 443	آیا دنیای بیرون می‌تواند درگاه 443 را برسد؟	firewall ابر آن را مسدود می‌کند. درگاه 443/TCP inbound باز کنید
DNS دامنه	آیا دامنه به IP سرور resolve می‌شود؟	رکورد DNS A به‌روز کنید
OS سرور	آیا Ubuntu/Debian است؟	بدون apt (CentOS، Fedora، Alpine) خطا می‌دهد؛ Ubuntu یا Debian نصب کنید
فضای دیسک	حداقل 2GB آزاد؟	فضا خالی کنید
هماهنگی ساعت	drift کلاینت/سرور کمتر از یک دقیقه است؟	یکی از دو طرف زمان را همگام نمی‌کند. NTP و زمان خودکار را روی هر دو دستگاه فعال کنید

تفسیر خروجی doctor

بخش	چه چیزی را جستجو کنید
ماشین محلی	سازگاری OS
سرور	نسخه OS، uptime (reboot اخیر؟)، استفاده دیسک/memory
Docker	آیا containers ctlsvc-api و netagent اجرا می‌شوند؟ وضعیت باید “Up” باشد
لاگ‌های گره Remnawave	خطاهای شروع گره، “failed to start” ورودی‌ها، مسائل certificate
درگاه‌های گوش‌دهنده	درگاه 443 باید nginx را نشان دهد. اگر گمشده، proxy اجرا نمی‌شود
firewall (UFW)	درگاه 443/tcp باید ALLOW باشد. اگر فهرست‌نشده، مسدود است
هدف SNI	باید CONNECTED را با یک زنجیره certificate نشان دهد
DNS دامنه	باید به IP سرور resolve شود

تفسیر خروجی test

بررسی	پاس	ناموفق یا پرش شد
قابلیت رسیدن TCP	هر listener عمومی TCP پیکربندی‌شده قابل دسترس است	firewall، ISP block، سرور خاموش یا توپولوژی غلط
پنهان‌سازی TLS/SNI	هدف هویت پنهان‌سازی انتظار را نشان می‌دهد	مسیریابی TLS، certificate، DNS یا عدم تطابق SNI
ریشه domain	پاسخ 403/404 سخت‌گیرانه قابل دسترس است	شکست DNS/nginx یا محتوای عمومی غیرقصد
subscription	Remnawave JSON Xray معتبر برای کلاینت فعال تحویل داد	کلاینت گمشده/غیرفعال، شکست پنل یا template شکسته
fallback خودکار	سیاست تحویل‌شده ترافیک واقعی را حمل کرد	balancer، مسیریابی، اعتبارنامه یا شکست endpoint
بررسی‌های پروتکل	هر listener outbound هدف ترافیک واقعی را حمل کرد	listener خاص پروتکل، firewall یا شکست config تحویل‌شده

test کامل observers IP عمومی مستقل را چرخش می‌دهد و observers یکسان را مستقیم بررسی می‌کند. اگر proxy نه مسیر کنترل نتوانند IP را دریافت کنند، نتیجه نامعین است تا شکست prot گل دروغی. تنها MERIDIAN_CONNECT_TEST_URL را زمانی تنظیم کنید که endpoint observer شناخته‌شده را اپریٹ کنید.

اولین test کامل ممکن است تا 120 ثانیه دانلود و تأیید انتشار Xray پین‌شده از GitHub صرف کند. بعد از bootstrap، --timeout (پیش‌فرض 5، محدوده 1-30) برای عملیات شبکه فردی اعمال می‌شود. خروج 0 کردند، 4 منفی یافته‌ها کامل، و 3 نامعین بود زیرا شواهد مورد نیاز پرش شد. حالت پایه‌ای نمی‌تواند ترافیک Hysteria فقط UDP تأیید کند.

اگر تمام بررسی‌های موفق اما کلاینت VPN همچنان نمی‌تواند اتصال برقرار کند: QR code را مجدد پوسش کنید، بررسی کنید که دستگاه تاریخ و زمان را به‌صورت خودکار تنظیم می‌کند یا برنامه دیگری امتحان کنید (v2rayNG، Hiddify).