استخر از کار افتاده: چطور بفهمیم مشکل از ASIC شما نیست و در ساعت اول چه کنیم

*Last updated: 09.09.2026. POOL BTC.*

TL;DR

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

POOL BTC استخر نیست، یک سایت مستقل مقایسه استخرهاست. ما خرابی را به استخر مشخصی نسبت نمی‌دهیم: آنچه در ادامه می‌آید یک روش است، نه کالبدشکافی از کار افتادن کسی.

چطور از کار افتادن استخر را از مشکل سمت خودتان تشخیص دهیم؟

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

بیایید بر اساس نشانه‌ها تفکیک کنیم. باید هم‌زمان به دو جا نگاه کرد: پنل ماینر (هش‌ریت محلی) و آمار حساب در استخر (هش‌ریت استخر).

یک حالت جداگانه هست که بیش از همه با از کار افتادن استخر اشتباه گرفته می‌شود: تنظیمات تازه. اگر هش‌ریت در استخر اصلاً هیچ‌وقت ظاهر نشده، این خرابی نیست، بلکه غلط تایپی در نام ورکر یا پورت بسته است. خرابی جور دیگری دیده می‌شود: روزها کار کرده و یک‌باره متوقف شده.

پنل ماینر هنگام قطع اتصال چه نشان می‌دهد و accepted، rejected، stale یعنی چه؟

در پنل ASIC برای هر استخر سه شمارنده وجود دارد: accepted (شرها پذیرفته شدند)، rejected (رد شدند)، stale (دیر رسیدند، کار دیگر معتبر نیست). هنگام قطع اتصال با استراتوم وضعیت استخر به dead یا disconnected تغییر می‌کند، شمارنده accepted متوقف می‌شود و ماینر شروع می‌کند به تلاش برای اتصال به استخر بعدی فهرست، اگر استخری آنجا نوشته شده باشد.

پشت این واژه‌ها چه چیزی هست:

• Accepted. استخر شر شما را پذیرفت و در آمار به حساب آورد. این تنها شمارنده‌ای است که به پول تبدیل می‌شود.
• Rejected. استخر شر را گرفت اما به حساب نیاورد. دلایلش متفاوت است: کار منقضی شده، تکراری بوده، دیفیکالتی خیلی پایین بوده، خطای احراز هویت.
• Stale. حالت خاصی از رد شدن: شر برای وظیفه‌ای محاسبه شده که استخر پیش‌تر لغوش کرده، چون در شبکه بلاک تازه‌ای پیدا شده. هرچه تأخیر تا سرور بیشتر باشد، این اتفاق بیشتر می‌افتد.
• Difficulty accepted. در برخی فرم‌ورها مجموع دیفیکالتی شرهای پذیرفته‌شده در یک سطر جداگانه می‌آید. این عدد از شمارنده تعداد گویاتر است، چون با vardiff تعداد شرها به‌تنهایی چیزی نمی‌گوید.

یک سطر دیگر هم ارزش نگاه کردن دارد: زمان آخرین شر پذیرفته‌شده (last share). اگر این عدد بالا برود و با وجود هش‌ریت پایدار از چند دقیقه بگذرد، اتصال عملاً مرده است، حتی اگر وضعیت استخر هنوز سبز باشد.

سازوکار شرها و اینکه چرا تعدادشان برابر درآمد نیست، در مقاله طرح‌های پرداخت FPPS و PPLNS مفصل‌تر بررسی شده است.

چند درصد ریجکت عادی شمرده می‌شود و چند درصد دیگر هشدار است؟

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

رویکرد عملی به جای عدد جادویی:

1. سهم rejected را در یک شبانه‌روز کار عادی اندازه بگیرید. این صفر شماست.
2. نه مقدار لحظه‌ای، بلکه میانگین یک‌ساعته را دنبال کنید. جهش‌های تکی هنگام تغییر بلاک عادی است، نه خرابی.
3. بالا رفتن این سهم در حالی که هش‌ریت محلی ثابت مانده یعنی مشکل از خط یا از استخر است، نه از سخت‌افزار.
4. بالا رفتن این سهم هم‌زمان با افت هش‌ریت محلی یعنی سخت‌افزار.

سه استخر معیارهای خودشان را اعلام می‌کنند و اختلافشان با هم از اختلاف ماینرهایی که در گروه‌ها جدل می‌کنند هم بیشتر است. AntPool در مرکز راهنمایش می‌نویسد که سهم ردشده‌های زیر ۱ درصد عادی است و شرهای منقضی حدود ۰٫۵ درصد و کمتر. ViaBTC بازه عادی رد شدن را تا ۳ درصد می‌داند. F2Pool سهم حدود ۲ درصد برای شرهای تأخیری را منطقی می‌شمارد. همین پراکندگی از ۰٫۵ تا ۳ درصد میان سه استخر بزرگ، خودش پاسخ پرسش درباره حد عادی است: حد عادی مشترکی وجود ندارد، آنچه هست تنظیمات یک استخر مشخص است.

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

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

چیزی که قطعاً عادی نیست و به آمار هم نیاز ندارد: سهم ردشده‌ها نزدیک صد درصد. این تقریباً همیشه دیفیکالتی نادرست، فرم‌ور خراب یا مسدود شدن اتصال توسط یک واسطه است، نه بار بیش از حد استخر.

برای تأیید از کار افتادن استخر کجا را نگاه کنیم؟

تأیید از کار افتادن همیشه یعنی یک منبع مستقل دوم. پنل خودتان به‌تنهایی کافی نیست: هم خرابی استخر و هم قطعی اپراتور اینترنت شما را یکسان نشان می‌دهد. ترتیب بررسی از سریع‌ترین به کندترین حدود پنج دقیقه وقت می‌گیرد و تقریباً همیشه پاسخ روشنی می‌دهد.

1. آمار هش‌ریت حساب در استخر. اگر پنل وب باز می‌شود و برای ورکر شما صفر نشان می‌دهد، سرور زنده است و فقط شرهای شما به آن نمی‌رسند. اگر پنل اصلاً بالا نمی‌آید، مشکل گسترده‌تر است.
2. صفحه وضعیت استخر. بخشی از استخرها صفحه جداگانه‌ای برای وضعیت سرویس‌ها دارند. آدرسش را بهتر است از قبل پیدا کنید و در بوکمارک نگه دارید، نه اینکه لحظه خرابی دنبالش بگردید.
3. مانیتورها و اکسپلوررهای شخص ثالث. ناظران عمومی توزیع هش‌ریت نشان می‌دهند که استخر همین حالا بلاک پیدا می‌کند یا نه. مکث طولانی در یک استخر بزرگ نشانه‌ای غیرمستقیم اما قوی است.
4. شبکه‌های اجتماعی و گروه‌های استخر. حساب رسمی و کانال تلگرام معمولاً زودتر از به‌روزرسانی صفحه وضعیت از خرابی خبردار می‌شوند. همان‌جا هم پیداست که ماینرهای دیگر شکایت دارند یا نه.
5. بررسی مسیر از سمت خودتان. یک telnet یا nc ساده به آدرس و پورت استراتوم از هر کامپیوتری در همان شبکه، در ده ثانیه از کار افتادن استخر را از مسدود شدن نزد اپراتور اینترنت جدا می‌کند.

اگر پنل استخر باز می‌شود، بلاک‌ها پیدا می‌شوند، گروه ساکت است و شرهای شما پذیرفته نمی‌شوند، خرابی از سمت شماست، نه از سمت استخر.

backup pool برای چیست و استراتوم پشتیبان را چطور درست بنویسیم؟

استخر پشتیبان یک سطر در کانفیگ ماینر است که دستگاه وقتی استراتوم اصلی جواب نمی‌دهد خودش به آن سوئیچ می‌کند. بدون آن، ASIC هنگام قطع اتصال فقط فن‌ها را می‌چرخاند و تا وقتی شما دخالت نکنید هیچ درآمدی ندارد. با آن، توقف به زمان اتصال دوباره کاهش پیدا می‌کند که با ثانیه اندازه‌گیری می‌شود، نه با ساعت‌های خواب شما.

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

```

pool1: stratum+tcp://[آدرس استخر اصلی]:[پورت] worker: حساب.ورکر

pool2: stratum+tcp://[آدرس استخر پشتیبان]:[پورت] worker: حساب۲.ورکر

pool3: stratum+tcp://[آدرس استخر سوم]:[پورت] worker: حساب۳.ورکر

```

قواعدی که بدون آن‌ها پشتیبان کار نمی‌کند:

1. استخر دوم یعنی استخری دیگر، نه پورت دیگری از همان استخر. آدرس پشتیبان درون همان زیرساخت، شما را از سقوط همان زیرساخت نجات نمی‌دهد. پورت یدکی استخر اصلی را در سطر سوم بگذارید، نه دوم.
2. حساب در استخر پشتیبان باید از قبل ساخته و آزموده شده باشد. ثبت‌نام در لحظه خرابی، همان ساعت اول را می‌بلعد.
3. آدرس پرداخت در استخر پشتیبان باید پر شده باشد. وگرنه آنچه استخراج شده روی موجودی‌ای معلق می‌ماند که یک ماه بعد سراغش می‌روید.
4. سوئیچ شدن را دستی امتحان کنید. استخر اصلی را در رابط کاربری برای چند دقیقه غیرفعال کنید و مطمئن شوید شرها به پشتیبان می‌روند و پس از برگرداندن، ماینر دوباره به استخر اول برمی‌گردد.
5. طرح پرداخت را در نظر بگیرید. جابه‌جایی رفت‌وبرگشتی میان استخرهای PPLNS انباشت داخل پنجره را دو بار صفر می‌کند، پس منطقی‌تر است استخری با طرح ساده‌تر را به عنوان پشتیبان بگذارید. تفاوت سازوکارها در مقایسه FPPS و PPLNS بررسی شده است.

تعداد نقاط ورود در دسترس نزد استخرها متفاوت است و از خود مستنداتشان پیداست. ما هاست‌های یکتای stratum برای BTC را در صفحات اتصال شش استخر شمردیم.

مهم این نیست که یک استخر هشت هاست دارد و دیگری یکی. مهم این است که همه این آدرس‌ها به یک زیرساخت می‌رسند: آن‌ها از سقوط یک منطقه نجاتتان می‌دهند، اما از سقوط خود استخر نه. دقیقاً به همین دلیل سطر دوم در کانفیگ باید به بیرون اشاره کند.

ماینر بابت هر ساعت توقف واقعاً چقدر پول از دست می‌دهد و خودمان چطور حسابش کنیم؟

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

فرمول:

```

زیان = (هش‌ریت بر حسب TH/s × هش‌پرایس بر حسب USD به ازای TH/s در روز) / ۲۴ × ساعت‌های توقف

```

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

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

هنگام محاسبه چه چیزی را نباید فراموش کرد:

• برق در زمان توقف تا حدی مصرف می‌شود. اگر ماینر روشن است اما نمی‌تواند شر بفرستد، باز هم برق می‌کشد. زیان واقعی هر ساعت به اندازه هزینه همین مصرف از درآمد از دست رفته بیشتر است.
• PPLNS توقف را دو بار جریمه می‌کند. در طرح‌های انباشتی شما نه‌تنها یک ساعت درآمد نداشته‌اید، بلکه جایگاهتان در پنجره را هم از دست داده‌اید و آن جایگاه فوری برنمی‌گردد. در طرح‌های شبیه PPS زیان دقیقاً برابر همان فرمول است.
• برای کل فارم حساب کنید، نه برای یک دستگاه. یک ساعت توقف ده دستگاه ده برابر گران‌تر تمام می‌شود و با دیدن همین عدد، تصمیم درباره استخر پشتیبان خودبه‌خود گرفته می‌شود.

محاسبه درآمد برای هش‌ریت خودتان و پارامترهای فعلی شبکه در ماشین‌حساب راحت‌تر است تا در ذهن.

در ساعت اول چه کنیم: چک‌لیست گام‌به‌گام

1. دقیقه ۰ تا ۲. به هش‌ریت محلی در پنل ماینر نگاه کنید. اگر همراه هش‌ریت استخر افت کرده، یعنی سخت‌افزار و ادامه این فهرست را لازم نیست بروید.
2. دقیقه ۲ تا ۵. وضعیت استخرها و زمان آخرین شر پذیرفته‌شده را بررسی کنید. وضعیت dead و زمانی که مدام بالا می‌رود، قطع اتصال را تأیید می‌کنند.
3. دقیقه ۵ تا ۱۰. پنل استخر و صفحه وضعیت را باز کنید. اگر هیچ چیز باز نمی‌شود، از جمله سایت‌های دیگر، یعنی مشکل از خط شماست.
4. دقیقه ۱۰ تا ۱۵. دسترسی به استراتوم را از دستگاه دیگری در همان شبکه و بعد از اینترنت موبایل بررسی کنید. تفاوت نتیجه به اپراتور اینترنت یا روتر اشاره می‌کند.
5. دقیقه ۱۵ تا ۲۰. سری به گروه و شبکه‌های اجتماعی استخر بزنید. شکایت‌های گسترده در چند دقیقه اخیر پرونده را می‌بندد.
6. دقیقه ۲۰ تا ۳۰. مطمئن شوید پشتیبان فعال شده است. اگر استخر پشتیبان در کانفیگ نیست، همین حالا بنویسیدش، این تنها کاری است که همین الان درآمد را برمی‌گرداند.
7. دقیقه ۳۰ تا ۴۵. دیگر به چیزی دست نزنید. ری‌استارت گروهی فارم، نصب دوباره فرم‌ور و تغییر دیفیکالتی در زمان خرابی دیگری، خرابی دومی روی خرابی اول اضافه می‌کند.
8. دقیقه ۴۵ تا ۶۰. واقعیت‌ها را ثبت کنید. زمان شروع، اسکرین‌شات پنل، زمان آخرین شر، پاسخ استخر. بدون این‌ها گفت‌وگو درباره جبران خسارت به جدل بر سر حافظه تبدیل می‌شود.

چه وقت توقف دلیل عوض کردن استخر است و چه وقت نیست؟

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

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

چرا تقریباً هیچ استخری uptime منتشر نمی‌کند و اعتمادپذیری را چطور غیرمستقیم بسنجیم؟

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

وقتی عدد آپ‌تایم وجود ندارد به چه چیزی نگاه کنیم:

• نظم بلاک‌های پیداشده. در یک استخر بزرگ، مکث‌ها بر اساس سهمش در شبکه قابل پیش‌بینی‌اند. سکوت به‌طور غیرعادی طولانی در هر اکسپلورر عمومی دیده می‌شود.
• وجود صفحه وضعیت و تاریخچه رخدادها. همین که استخر دفتر عمومی خرابی‌ها را نگه می‌دارد، بیشتر از عدد زیبای ۹۹٫۹ حرف می‌زند.
• سرعت و پرمایگی ارتباط. پیامی در گروه در دقایق اول خرابی از پست عذرخواهی روز بعد ارزشمندتر است.
• تعداد نقاط ورود مستقل. مناطق مختلف، آدرس‌های استراتوم مختلف، پشتیبانی از چند پورت. این‌ها احتمال از دست دادن کامل ارتباط را کم می‌کنند.
• نظر ماینرها درباره خرابی‌های گذشته. نه درباره وجود خرابی، بلکه درباره اینکه آمار پس از آن‌ها جور درآمد یا نه.

ما مطالب عمومی هشت استخر را در ۰۹٫۰۹٫۲۰۲۶ بررسی کردیم. صفحه وضعیت کامل با تاریخچه رخدادها و اعداد آپ‌تایم فقط نزد یکی پیدا شد: Luxor آن را در uptime.luxor.tech منتشر می‌کند، با تفکیک بر اساس سرویس‌ها (رابط استخر ۹۹٫۷۶۶ درصد، پردازش آمار ۹۹٫۹۵۶ درصد، بخشی از سرویس‌ها ۱۰۰ درصد) و با دفتر سه ماه اخیر. Foundry صفحه status.foundry.ac را دارد، اما این وضعیت سرویس‌های شرکتی Foundry Digital است، نه صفحه‌ای جداگانه برای استخر ماینینگ. F2Pool بخش اطلاعیه‌ها را با پست‌هایی درباره رخدادها نگه می‌دارد، اما این صفحه وضعیت نیست. نزد ViaBTC عدد ۹۹٫۹۹ درصد در مطالب بازاریابی دیده می‌شود، اما صفحه‌ای که بشود آن را وارسی کرد پیدا نکردیم. نزد AntPool، Braiins Pool، Binance Pool و Ocean صفحه وضعیت عمومی با جست‌وجو یافت نشد. این آخری دقیقاً یعنی «در چارچوب بررسی پیدا نشد»، نه نبودن قطعی.

بررسی صفحات عمومی استخرها، ۰۹٫۰۹٫۲۰۲۶.

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

خلاصه

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