اول فرض کار را روشن کنیم: ممکن است ده کارت در فهرست پروفایل‌ها باشد، ولی در هر لحظه فقط کارت فعال اجرا می‌شود. عوض کردن پروفایل به سبکی عوض کردن گره نیست؛ کل مجموعه جا‌به‌جا می‌شود: گره‌ها، گروه‌ها، قانون‌ها و بخش DNS. با روشن شدن همین نکته، هزینه دو راه بعدی راحت حساب می‌شود.

راه الف: دستی کارت‌ها را عوض کنید

ساده‌ترین گزینه است و به هیچ YAML دست نمی‌زند. روزها سرویس‌دهنده الف، شب‌ها برای تماشای ویدیو سرویس‌دهنده ب، با یک کلیک روی کارت. این راه وقتی جواب می‌دهد که کاربرد دو پروفایل از پیش از هم جدا باشد، به‌ویژه اگر یکی از آن‌ها مجموعه قانونی دارد که کس دیگری نوشته و ترجیح می‌دهید دست‌نخورده بماند.

  • جابه‌جایی اتصال‌ها را از نو می‌سازد. دانلود نیمه‌کاره قطع می‌شود، ویدیو می‌پرد و پیام‌رسان‌هایی که اتصال بلندمدت دارند دوباره وصل می‌شوند. وسط انتقال فایل این کار را نکنید.
  • قانون‌های دو پروفایل معمولاً یکی نیستند. سایتی که زیر الف از پروکسی می‌رود و زیر ب با یک قانون مستقیم می‌شود، حس سایتی را می‌دهد که بعضی روزها کار می‌کند و بعضی روزها نه؛ در حالی که این پیکربندی است که زیر پایش عوض شده.
  • بعد از برگشتن، گره انتخاب‌شده در گروه دستی لزوماً همانی نیست که گذاشته بودید. انتخاب گروه‌ها معمولاً برای هر پروفایل جداگانه به خاطر سپرده می‌شود.
پیشنهاد همکاریلینک اشتراک را از کجا بیاوریم؟سرویس همکار ما هنگام ثبت‌نام ۱ گیگابایت ترافیک پرسرعت هنگ‌کنگ رایگان می‌دهد.دریافت سرور پرسرعت

راه ب: با proxy-providers ادغامشان کنید

نگاه را برعکس کنید: اشتراک را پیکربندی حساب نکنید، منبع گره حساب کنید. کار proxy-providers دقیقاً همین است. هر اشتراک به‌عنوان یک provider ثبت می‌شود، کلاینت هرکدام را جداگانه می‌گیرد و کش می‌کند، و گره‌ها به گروه‌هایی می‌ریزند که خودتان نوشته‌اید. فقط گره‌ها می‌آیند — قانون‌ها و گروه‌ها مال خود شما می‌مانند و هیچ چیزی از مجموعه قانون سرویس‌دهنده‌ها همراه گره‌ها وارد نمی‌شود.

proxy-providers:
  vendor-a:
    type: http
    url: "https://a.example.com/link?token=AAA"
    path: ./providers/vendor-a.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
  vendor-b:
    type: http
    url: "https://b.example.com/link?token=BBB"
    path: ./providers/vendor-b.yaml
    interval: 86400
    filter: "HK|SG|JP"
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
proxy-groups:
  - name: PROXY
    type: select
    use:
      - vendor-a
      - vendor-b

url همان لینک اشتراک آن سرویس‌دهنده است، دقیقاً همان رشته‌ای که در حالت عادی در صفحه پروفایل‌ها می‌چسباندید. path فایل کش محلی است و دو منبع نباید نام فایل مشترک داشته باشند، وگرنه روی هم می‌نویسند و نشانه‌اش تعداد گره‌ای است که مدام کم و زیاد می‌شود. واحد interval ثانیه است، پس 86400 یعنی یک روز. health-check سنجش تأخیر مخصوص همین مجموعه است و با دکمه تست سراسری فرق دارد. گروه‌ها با use به provider وصل می‌شوند و این کلید می‌تواند کنار proxies بیاید، پس گره‌های ثابتی که دستی نوشته‌اید هم در همان فهرست می‌مانند. اگر می‌خواهید سریع‌ترین به‌طور خودکار انتخاب شود، type را url-test بگذارید.

بعد از ادغام، نام‌ها به هم می‌خورند

  • چند سرویس‌دهنده گره‌ای به نام HK 01 دارند و در یک فهرست درهم معلوم نیست کدام مال کیست. ارزان‌ترین راه‌حل یک filter روی هر provider است: یک عبارت باقاعده که با نام گره‌ها سنجیده می‌شود و فقط همان بخشی را نگه می‌دارد که واقعاً می‌خواهید — مثلاً از سرویس‌دهنده ب فقط مسیرهای ژاپن.
  • filter اشتباه خودش را این‌طور نشان می‌دهد که آن منبع اصلاً هیچ گره‌ای نمی‌آورد و نصف گروه غیب می‌شود. بعد از هر ویرایش، اول ببینید گروه خالی نشده باشد و بعد سراغ تست تأخیر بروید.
  • نسخه‌های تازه‌تر mihomo می‌توانند نام‌ها را در سطح provider بازنویسی کنند و یک پیشوند مشترک روی منبع بگذارند. اینکه هر کلاینت چه نسخه‌ای از هسته را در خود دارد فرق می‌کند، پس اگر مطمئن نیستید پشتیبانی می‌شود، به‌جایش با filter نام‌های تکراری را حذف کنید؛ نتیجه عملی تقریباً یکی است.

بهای ادغام

  • عددهای حجم و انقضا از دست می‌روند. آن ارقام از پاسخ اشتراک می‌آیند و بعد از ادغام، پیکربندی شما خودش اشتراک نیست، پس باقی‌مانده حجم را باید در پنل هر سرویس‌دهنده جداگانه ببینید.
  • یک منبع خراب همه را کند می‌کند. اگر provider گرفته نشود یا کل دسته گره‌هایش timeout بخورد، هر دور health-check منتظر همان timeout‌ها می‌ماند و گروه url-test به‌وضوح دیرتر جواب می‌دهد. هر چه مدت‌هاست خراب مانده را کامنت کنید.
  • پیدا کردن منشأ خطا سخت‌تر می‌شود. اسم provider‌ها را طوری بگذارید که بشناسید، وگرنه لاگ نمی‌گوید کدامشان شکست خورده.
  • نگهداری این پیکربندی از این به بعد با شماست. قانون‌ها و گروه‌های تازه‌ای که سرویس‌دهنده بعداً اضافه می‌کند هرگز به شما نمی‌رسد.

با خودِ آینده‌تان مهربان باشید

نام‌ها بیش از آنچه به نظر می‌رسد ارزش دارند. یک دسته کارت که همه‌شان Subscription نامیده شده‌اند نگه ندارید؛ چیزی بنویسید که با یک نگاه خوانده شود، مثلاً نام کوتاه سرویس‌دهنده به‌علاوه ماه انقضا، تا مرور فهرست بگوید کدام دارد تمام می‌شود. آن‌هایی را که دیگر پولش را نمی‌دهید پاک کنید و نگه ندارید: کلاینت سر وقت سراغشان می‌رود، هر بار شکست می‌خورد و انبوهی خط قرمز جمع می‌کند که دفعه بعد هنگام عیب‌یابی چیز دیگری باید از میانشان بگذرید. اشتراک‌های آزمایشی را جدا نگه دارید و با تمام شدن دوره پاکشان کنید.

اول تصمیم بگیرید کدام را می‌خواهید. گره‌های چند سرویس‌دهنده کنار هم در یک فهرست یعنی ادغام. عوض کردن کل مجموعه با مجموعه‌ای دیگر یعنی جابه‌جایی کارت‌ها، و ارزشش را ندارد که برای پرهیز از یک کلیک، پیکربندی سالمی را خراب کنید. یک تفکیک هم بگویم: این نوشته درباره هم‌زیستی چند منبع است، و اینکه تغییرهای خودتان با یک به‌روزرسانی پاک نشوند موضوع آموزش ادغام و بازنویسی پیکربندی است. این دو را اغلب با هم انجام می‌دهند، ولی یک کار نیستند.