Pool
DIAGNOSTICSMONITORINGLOGREPORT INTERMEDIATE

채굴기 로그 리더 — SoloFury 채굴기 보고서 해석 방법

/miner/ 페이지에서 생성된 .log 보고서를 읽는 완전 가이드. 모든 섹션, 모든 메트릭, 각 경고에 대한 대응 방법을 이해합니다.

Updated: May 18, 2026 · 5 min read

SoloFury Miner Log Report/miner/ 페이지에서 온디맨드로 생성되는 솔로 채굴 활동의 완전한 텍스트 스냅샷입니다. 실시간 해시레이트, 워커별 건강 진단, 셰어 품질, 난이도 최적화 제안, ASCII 차트가 있는 24시간 통계, 발견된 블록, 풀/네트워크 컨텍스트를 포함합니다 — 저장하거나 공유하거나 스크립트에 전달할 수 있는 자체 포함 .log 파일로.

대시보드 스크린샷과 달리, 로그는 구조화된 텍스트로 기록 보관을 위해 저장하거나, 지원팀과 공유하거나, 스크립트로 파싱하거나, 풀 문제 발생 시 증거로 첨부할 수 있습니다.

로그 다운로드 방법

  1. URL에 지갑을 포함하여 solofury.com/miner/를 엽니다: ?addr=당신의지갑&coin=COIN
  2. 대시보드가 완전히 로드될 때까지 기다립니다(3〜5초 — 보고서는 라이브 API 데이터 사용)
  3. 아이덴티티 카드의 오른쪽 상단 .LOG 버튼을 클릭합니다
  4. 브라우저가 solofury-COIN-WALLET-DATE.log라는 이름의 파일을 다운로드합니다

1. Executive Summary

한눈에 보는 개요: 상태, 워커, 현재 해시레이트와 24h 평균 비교, 라이프타임 블록, 총 채굴량, 주요 문제. 이것을 먼저 읽으세요 — 조사할 것이 있는지 알려줍니다.

상태 값

  • ✓ ALL GOOD — 모든 워커가 건강함, 25%를 초과하는 저하 없음
  • ⚠ ISSUES DETECTED — 하나 이상의 워커에 경고 있음 (25〜50% 하락, 3〜10분 늦은 셰어)
  • ⚠ CRITICAL — 하나 이상의 워커가 오프라인(>10분) 또는 심각하게 저하됨(>50%)

“Top issues to investigate” 목록이 가장 긴급한 항목을 나열합니다. 보고서가 ALL GOOD이면 읽기를 멈추고 내일 다시 확인할 수 있습니다.

2. Overview

지갑 수준의 집계 통계:

  • Hashrate snapshot — 다양한 시간 창의 이동 평균. 1m이 가장 불안정; 7d가 가장 안정적인 기준.
  • Workers / ASIC online — 활성 채굴기 수.
  • Shares (lifetime) — 지갑이 처음 연결된 이후 총계. 승인됨/거부됨/무효/오래됨/중복 분류.
  • Efficiency — 제출된 셰어 중 승인된 비율. 목표: 99.9%+.
  • Luck (round) — 현재 블록 라운드의 운. 100%를 넘으면 블록 발견을 위해 통계적으로 기대되는 것보다 더 많은 셰어를 이미 제출했음을 의미.
  • Best share / Best ever — 가장 높은 난이도의 셰어. 네트워크 목표에 가까울수록 블록 발견에 가까움.

3. Worker Health Analysis

이것이 문제 해결에서 가장 중요한 섹션입니다. 분석기는 각 워커의 현재 해시레이트를 1h와 24h 이동 평균과 비교하고, 마지막으로 셰어를 제출한 시간을 확인합니다.

심각도 수준

심각도트리거의미
OK해시레이트가 24h 평균의 25% 이내
마지막 셰어가 3분 미만
워커가 건강함
WARN해시레이트가 평균보다 25〜50% 낮음
또는 마지막 셰어가 3〜10분 전
경미한 문제, 모니터링
CRITICAL해시레이트가 평균보다 50% 초과 낮음
또는 마지막 셰어가 10분 초과 전
오프라인 가능성, 개입 필요

대처 방법 — 일반적인 경우

  • 오프라인 > 10분 — 전원, 네트워크 케이블, stratum URL 연결 가능 여부 확인
  • 해시레이트 -50% 이상 — 열 스로틀링 또는 해시보드 고장 가능성; 먼저 냉각 확인
  • 해시레이트 -25〜-50% — 경미한 저하, 행동하기 전 30분 모니터링
  • 셰어는 늦지만 정상 해시레이트 — 네트워크/stratum 문제; 연결된 릴레이(Frankfurt/Atlanta/Singapore) 확인

로그에는 각 문제 있는 워커에 대한 특정 문제에 맞춤화된 제안 조치가 포함되어 있습니다.

4. All Workers (테이블)

상태에 관계없이 모든 워커의 전체 표 형식 보기. 성능을 나란히 비교하는 데 유용합니다.

열 설명

  • HASHRATE / 1H AVG / 24H AVG / 7D AVG — 다양한 시간 창의 평균. 7d가 “실제” 능력을 보여줍니다.
  • UPTIME — 워커가 연결된 총 시간(첫 셰어 이후).
  • BEST DIFF — 이 워커가 제출한 가장 높은 난이도의 셰어. 높을수록 블록에 가까움.
  • LAST SHARE — 워커가 마지막 셰어를 제출한 이후 시간. 정상 작동 시 <1min이어야 함.
  • STATUS — 현재 건강 상태(섹션 3 참조).

5. Difficulty Optimization

풀은 vardiff(가변 난이도)를 사용: 각 워커가 약 10초마다 1개의 셰어를 제출하도록 셰어 난이도를 자동 조정합니다. 이 섹션은 현재 난이도가 최적인지 보여줍니다.

공식

optimal_diff = hashrate × 10 / 2³²

조치

  • ↑ raise +X% — 현재 diff가 너무 낮음; 낮은 가치의 셰어로 풀을 넘치게 하고 있습니다. 풀이 자동으로 조정합니다(또는 password=d=NUMBER로 수동 설정 가능).
  • ↓ lower -X% — 현재 diff가 너무 높음; 원활한 추적을 위해 제출하는 셰어가 너무 적습니다. 낮은 해시레이트 Bitaxe에 특히 관련됩니다.
  • ≈ already optimal — 조치 불필요.

6. Share Quality Analysis

유형별 셰어 거부 분류:

  • Reject — 제출되었지만 유효하지 않음(잘못된 목표, 나쁜 작업). 종종 네트워크 손상 또는 펌웨어 문제를 가리킵니다.
  • Invalid — 잘못된 형식의 셰어. 거의 0에 가까워야 합니다.
  • Stale — 오래된 블록의 셰어(새 블록이 들어왔을 때 채굴기가 아직 이전 블록에 있었음). 약간의 staleness는 정상; >1%는 풀에 대한 지연을 시사.
  • Duplicate — 같은 셰어가 두 번 제출됨. 보통 네트워크 결함.

품질 배지

  • ⭐ Excellent — 불량 셰어 비율 < 0.1%(천 분의 일 또는 더 드물게)
  • ✓ Good — 불량 셰어 비율 < 1%
  • ⚠ Below normal — 불량 셰어 비율 > 1%; 네트워크 또는 펌웨어 조사

7. Statistics (last 24h)

24h 차트 엔드포인트에서 집계된 메트릭(5분마다 샘플):

  • Hashrate avg / max / min — 일일 범위. min과 max의 큰 차이는 불안정을 시사.
  • Peak vs avg — 피크가 평균보다 얼마나 높은지. <20%는 부드러움; >50%는 on/off 동작을 시사.
  • Effective uptime — 평균의 10% 이상 해시레이트가 있었던 샘플의 비율. 100%는 지속 작동을 의미.
  • Shares 24h — 일일 셰어 수. 평소 기준선과 비교하여 후퇴를 발견합니다.

8. Wallet-Level Outages

지난 24h에 지갑 전체 해시레이트가 평균의 15% 미만으로 떨어진 지갑 전체 정전을 나열합니다. 다음과 같은 경우를 포착합니다:

  • 채굴 시설의 정전
  • 귀하 측의 네트워크 오류
  • 풀 측 중단(드물지만 가능)

워커별 문제(여러 채굴기 중 하나만 실패한 경우)는 여기에 표시되지 않습니다 — 섹션 3에 있습니다.

9. Hashrate Timeline (24h)

24시간 해시레이트 변화의 2부 구성 보기:

  • ASCII 차트 — 해시레이트 곡선의 빠른 시각적 스케치. Y축 레이블은 절대값 표시; X축은 24h 전부터 지금까지.
  • 시간별 스냅샷 — 시간당 1행, 그 시점의 해시레이트와 네트워크 난이도를 표시.

패턴을 발견하는 데 사용합니다: 일일/주간 사이클, 느린 하락, 급격한 하락.

10. Blocks Found by this Wallet

이 풀에서 지갑이 발견한 블록의 실제 목록. 각 항목에는 다음이 표시됩니다:

  • HEIGHT — 블록체인 블록 높이(어떤 블록 탐색기에서도 확인 가능)
  • DATE — 블록의 UTC 타임스탬프
  • WORKER — 승리 셰어를 제출한 특정 워커

이 데이터는 지갑 주소로 필터링된 풀의 블록 API에서 가져옵니다.

11. Network Context

코인의 더 넓은 블록체인 컨텍스트:

  • Network hashrate / difficulty — 전체 블록체인의 현재 합계.
  • Your share of net — 기여하는 네트워크 총 해시레이트의 비율.
  • Statistical TTF — 다음 블록을 찾기까지의 통계적 Time To Find. 1 / (당신의HR / 네트워크HR × 하루블록수)로 계산. 실제 운은 크게 변동합니다: 1시간에 블록을 찾을 수도 있고 통계적 TTF의 10배가 걸릴 수도 있습니다.

12. Pool Context

SoloFury 풀 전체 통계: 해시레이트, 채굴자, 워커, 유휴/연결 해제 수, 수수료, 운, 업타임. 자체 설정을 문제 해결할 때 풀이 건강한지 확인하는 데 사용합니다. 풀 통계가 정상으로 보이지만 채굴기에 문제가 보이면 문제는 귀하 측에 있습니다.

자주 묻는 질문

얼마나 자주 로그를 다운로드해야 하나요?

적극적인 모니터링의 경우: 하루에 한 번 또는 비정상적인 동작을 발견할 때마다. 기록 보관의 경우: 주간 또는 월간. 로그는 작습니다(~10〜50KB) 따라서 많이 저장해도 괜찮습니다. 헤더의 고유한 Report ID로 지원 이메일에서 특정 보고서를 참조할 수 있습니다.

.log 생성을 스크립트화할 수 있나요?

직접은 아닙니다(버튼은 클라이언트 측 JS를 실행), 하지만 동일한 기본 API 데이터를 가져올 수 있습니다: https://solofury.com/api/client/당신의지갑, /api/pool, /api/client/당신의지갑/chart?range=24h. 모두 JSON을 반환합니다. 어떤 언어로든 이 엔드포인트에서 자체 보고서를 구성할 수 있습니다.

로그가 워커의 해시레이트 하락을 보이지만 대시보드는 정상으로 보입니다 — 왜인가요?

“now” 값은 1h/24h 평균이 낮게 유지되는 동안 잠깐 급등할 수 있습니다(슬라이딩 윈도우). “now” > “1h avg”이지만 로그가 “24h avg”에 대한 하락을 경고한다면, 워커가 하루 대부분을 용량 이하로 운영했지만 방금 다시 올라왔음을 의미합니다. 로그는 지속적인 문제를 포착하기 위해 장기 참조값과 비교합니다.

”Statistical TTF”가 30일이라고 합니다 — 30일 안에 블록을 찾는다는 의미인가요?

아니오. 통계적 TTF는 예상되는 평균 시간입니다. 블록 발견의 지수 분포로 인해 1 TTF(여기서 30일) 내에 블록을 찾을 확률은 ~63%, 2 TTF(60일) 내에서 ~86%, 3 TTF(90일) 내에서 ~95%입니다. 어떤 주에는 두 블록을 찾고 다른 주에는 없을 수도 있습니다. 이것이 솔로 채굴의 본질입니다.

”Rejected”와 “Invalid” 셰어의 차이는 무엇인가요?

Rejected: 셰어는 형식적으로 유효했지만 목표 난이도를 충족하지 못했습니다(오래된 작업이나 낮은 diff로 인한 경우가 많음). Invalid: 셰어가 잘못된 형식(잘못된 형식, 나쁜 nonce). Invalid는 거의 항상 소프트웨어/펌웨어 버그입니다. Rejected는 소량으로 정상일 수 있습니다(네트워크 지연).

”LATE share”가 표시되지만 워커가 채굴 중입니다 — 무엇이 문제인가요?

“LATE share”는 마지막 셰어로부터 3분 초과를 의미합니다. 가능한 원인: stratum으로의 네트워크 차단, 매우 높은 난이도(낮은 셰어 빈도 예상), 또는 채굴기가 오프라인이지만 풀이 아직 완전히 감지하지 못함. 대시보드 해시레이트로 상호 확인합니다. 해시레이트가 여전히 표시되면 보통 일시적인 연결 문제입니다.

더 많은 도움을 어디서 받을 수 있나요?

.log 파일을 첨부하여 [email protected]로 이메일을 보내세요. 헤더의 Report ID를 포함하세요 — 서버 측 로그와 상관관계를 파악하는 데 도움이 됩니다. 풀 팀은 24시간 내 응답을 목표로 합니다.