این سه مسیر به سه نوع ماشین می‌خورند. رایانه رومیزی که هر روز با آن کار می‌کنید برنامه گرافیکی می‌خواهد. یک VPS در مرکز داده هیچ استفاده‌ای از میزکار ندارد و هسته خام برایش کافی است. و اگر باید هنگام بوت بالا بیاید و بعد از کرش خودش را برگرداند، دور همان هسته خام یک unit سیستمی می‌پیچید — دو مسیر آخر در واقع دو نیمه یک مسیرند: اول دستی راهش بیندازید، بعد تحویل سیستم بدهید.

مسیر یک: برنامه گرافیکی

  1. قالب بسته را در صفحه انتشار پروژه انتخاب کنید: deb برای Debian و Ubuntu، rpm برای Fedora و openSUSE، و AppImage برای بقیه. زیر هر نسخه همه معماری‌ها کنار هم قرار دارند، پس روی ماشین x86 بسته arm64 برندارید.
  2. بسته deb را با sudo apt install ./نام‌فایل و بسته rpm را با sudo dnf install ./نام‌فایل نصب کنید. آن ./ ابتدای مسیر اختیاری نیست؛ بدون آن، مدیر بسته دنبال نرم‌افزاری با همان نام در مخزن‌ها می‌گردد. dpkg و rpm هم مستقیم کار می‌کنند اما هیچ‌کدام وابستگی‌ها را برایتان حل نمی‌کنند.
  3. برای AppImage اول مجوز اجرا بدهید، یعنی chmod +x، بعد دوبار کلیک کنید یا از ترمینال اجرایش کنید. چیزی در پوشه‌های سیستمی نمی‌نویسد، پس پاک کردن فایل همان حذف نصب است.
  4. بار اول حتماً از ترمینال اجرا کنید، نه از منوی برنامه‌ها. وقتی اجرا شکست بخورد پنجره یک لحظه ظاهر می‌شود و می‌رود، و تنها جایی که پیام خطا باقی می‌ماند ترمینال است.

شایع‌ترین شکست، نبودِ یک کتابخانه اجرایی است. AppImage فقط کد خود برنامه را بسته‌بندی می‌کند و GTK و WebKit و امثال آن‌ها را از سیستم قرض می‌گیرد؛ بنابراین وقتی یکی نباشد، ترمینال نام دقیق همان فایل .so را می‌گوید. همان نام را در مدیر بسته جست‌وجو کنید تا معمولاً به بسته درست برسید؛ نام‌گذاری میان توزیع‌ها یکسان نیست، در خانواده Debian چیزی شامل webkit2gtk است و در Fedora و Arch هرکدام املای خودشان را دارند. آیکون سینی داستان جداگانه‌ای است: GNOME به‌طور پیش‌فرض ناحیه سینی را نمی‌کشد و تا افزونه AppIndicator نصب نشود چیزی ظاهر نمی‌شود، و در نشست‌های Wayland گم شدن آیکون بیشتر از X11 اتفاق می‌افتد — اگر افزونه نصب است و باز خبری نیست، یک بار با نشست X11 وارد شوید تا معلوم شود مشکل از همین‌جاست یا نه.

پیشنهاد همکاریلینک اشتراک را از کجا بیاوریم؟سرویس همکار ما هنگام ثبت‌نام ۱ گیگابایت ترافیک پرسرعت هنگ‌کنگ رایگان می‌دهد.دریافت سرور پرسرعت

مسیر دو: فقط هسته mihomo

uname -m
chmod +x ./mihomo
sudo install -m 755 ./mihomo /usr/local/bin/mihomo
mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

اگر uname -m پاسخ x86_64 داد، بسته amd64 را بردارید و اگر aarch64 داد، بسته arm64 را. اشتباه در همین قدم باعث می‌شود پوسته بگوید باینری قابل اجرا نیست، و این هیچ ربطی به پیکربندی شما ندارد. صفحه‌های انتشار معمولاً یک فایل فشرده منتشر می‌کنند که نام بازشده‌اش معماری و نسخه را با خود دارد؛ آن را به mihomo تغییر نام دهید تا بقیه دستورها کوتاه بماند. سوییچ -d به پوشه پیکربندی اشاره می‌کند و داخل آن دست‌کم باید یک config.yaml باشد. بار اول آن را به پس‌زمینه نفرستید؛ بگذارید در ترمینال چاپ کند تا ببینید اشتراک خوانده شد و پورت واقعاً بالا آمد یا نه. اگر ابزاری برای مدیریتش می‌خواهید، external-controller را فعال کنید و یک داشبورد وب به آن وصل کنید، که خودش موضوع جداگانه‌ای است.

مسیر سه: ماندگار کردن با systemd

[Unit]
Description=mihomo daemon
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target

هر دو مسیر داخل ExecStart باید با جایی که واقعاً فایل‌ها را گذاشته‌اید بخواند — اول باینری، بعد پوشه پیکربندی — و رونویسی عیناً به‌احتمال زیاد بالا نمی‌آید. مقدار User اینجا root است تا TUN و پورت‌های پایین کار کنند؛ اگر TUN نمی‌خواهید، کاربر عادی انتخاب امن‌تری است. عبارت Restart=on-failure فقط پس از خروج غیرعادی آن را برمی‌گرداند، پس اگر می‌خواهید در هر حالتی زنده بماند به always تغییرش دهید. محل درست فایل unit میان توزیع‌ها کمی فرق دارد و دستور sudo systemctl edit --force --full mihomo.service کاری می‌کند که systemd خودش فایل را بسازد تا لازم نباشد مسیر را حفظ کنید. بعد sudo systemctl daemon-reload و سپس sudo systemctl enable --now mihomo. از آن به بعد systemctl status mihomo می‌گوید زنده مانده یا نه و journalctl -u mihomo -f لاگ را دنبال می‌کند؛ همان چند خطی که خود هسته می‌نویسد روشن می‌کند که پیکربندی تجزیه نشده یا پورت اشغال بوده.

TUN در لینوکس یک قدم اضافه می‌خواهد

همان کلید TUN که در ویندوز با یک کلیک و نصب یک سرویس تمام می‌شود، اینجا رفتار دیگری دارد. ساختن آداپتور مجازی و بازنویسی جدول مسیریابی جزو اختیارات مدیریت شبکه است و پردازه‌ای که با کاربر عادی اجرا شده آن‌ها را ندارد. نشانه‌اش همیشه یکسان است: کلید خودش به حالت خاموش برمی‌گردد، یا خط‌های مربوط به TUN در لاگ صریح می‌گویند مجوز کافی نبوده یا دستگاه باز نشده. دو راه بیرون رفتن — کلاینتی که از deb یا rpm نصب شده معمولاً یک حالت سرویس دارد، آن را روشن کنید تا نیمه پرمجوز آداپتور را بسازد، یا سرویس را کنار بگذارید و همین اختیار را مستقیم به باینری بدهید:

sudo setcap cap_net_admin,cap_net_bind_service=+ep $(which mihomo)
getcap $(which mihomo)

چند نکته کوچک‌تر که پایتان را می‌گیرد

  • setcap روی AppImage تقریباً بی‌فایده است. زمان اجرا، AppImage محتوایش را در یک پوشه موقت سوار می‌کند و برنامه را از آنجا اجرا می‌کند، پس اختیاری که به فایل بیرونی چسبانده‌اید هرگز به پردازه واقعی نمی‌رسد. اگر TUN لازم دارید، از بسته deb یا rpm با حالت سرویس استفاده کنید و وقتتان را اینجا نسوزانید.
  • با هر بار جایگزینی باینری، اختیار از بین می‌رود. setcap روی خود فایل علامت می‌گذارد، پس بعد از هر ارتقای هسته یا تعویض فایل دوباره اجرایش کنید و با getcap مطمئن شوید هنوز برقرار است.
  • برنامه‌های داخل ترمینال تنظیم پروکسی سیستمی را کاملاً نادیده می‌گیرند. curl و git و مدیر بسته متغیرهای محیطی مثل https_proxy را می‌خوانند؛ دستور export https_proxy=http://127.0.0.1:7890 برای یک پوسته کافی است و ماندگار کردنش موضوع جداگانه‌ای است.
  • پیش از اجرا هش را بررسی کنید. صفحه‌های انتشار معمولاً کنار بسته‌ها فایل checksum هم می‌گذارند و روش مقایسه در نوشته‌ای جداگانه آمده است.
نگذارید کلاینت گرافیکی و سرویس systemd هم‌زمان اجرا باشند. هر دو همان پورت را می‌خواهند، آنکه دوم بالا می‌آید معمولاً بی‌صدا شکست می‌خورد، و شما به کلاینتی خیره می‌مانید که می‌گوید متصل است در حالی که پیکربندی دیگری کار را انجام می‌دهد — این وضعیت بیش از هر چیز دیگری در این نوشته وقت عیب‌یابی می‌گیرد. اگر کلاینت گرافیکی را نصب کرده‌اید ولی unit دست‌ساز هنوز سر جایش است، با sudo systemctl disable --now mihomo غیرفعالش کنید.