가정용 채굴기가 해시를 못 하나요? 완전 문제 해결 바이블 (2026)

아무 날이나 가정용 채굴 커뮤니티를 뒤져 보면 언제나 같은 글이 올라와 있습니다. 부팅은 되는데 0 GH/s에서 멈춘 Bitaxe, 2분마다 재부팅되는 NerdQaxe, 펌웨어 업데이트 후 해시레이트가 반토막 난 Gamma, 그리고 풀 쪽에서는 아무것도 보이지 않는데 해시 중이라고 주장하는 기계. 이 기기들은 재생 산업용 실리콘 위에서 오픈소스 펌웨어를 돌리는 오픈소스 하드웨어이며, 그 조합은 강력하고 저렴하면서 동시에 가전제품이라면 결코 그렇지 않을 방식으로 진짜 예민합니다.

이 가이드는 누군가의 디버깅을 도울 때마다 있었으면 했던 그 참고서입니다. 죽었거나 말썽을 부리는 거의 모든 개체를 설명할 수 있는 여섯 개의 고장 영역을 다루고, 수리 작업대가 하는 방식으로 로그를 읽는 법을 알려주며, 증상 마스터 표와 실제로 마주치게 될 오류 줄 사전으로 마무리합니다. 대상은 AxeOS 계열 전체입니다. 모든 Bitaxe(Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), ++와 Hydro를 포함한 NerdAxe 및 NerdQaxe 제품군, NerdOctaxe, 그리고 확장하여 BM1373 시대 레퍼런스에서 다룬 새 BM1373 기기를 포함한 모든 ESP-Miner 파생 기종입니다.

다른 모든 것에 앞서는 원칙이 하나 있습니다. 손대기 전에 진단하라. 이 가이드의 작업 순서에는 이유가 있으며, 각 단계가 원인의 한 부류를 통째로 제거합니다. 진짜 문제가 전원 전압 강하인데 곧장 펌웨어 재플래싱으로 건너뛰면 저녁 하나를 날리고, 문제가 하나에서 둘로 늘어날 수도 있습니다.

시간이 없나요? 대부분의 경우를 해결하는 다섯 가지

다른 무엇을 읽기 전에 이 다섯 가지를 순서대로 시도해 보세요. 이것만으로도 공구도 로그도 케이스를 여는 일도 없이 “내 채굴기가 죽었다”는 신고의 대다수가 해결됩니다.

1. 콜드 전원 사이클을, 제대로.
   전원 커넥터 자체를 뽑는다(벽 스위치가 아니라).
   꼬박 60초를 센다. 다시 꽂는다.
   이유: 레귤레이터 결함은 "래치"되며 모든 소프트웨어
   재시작을 살아남는다. 진짜 차단만이 그것을 지운다.

2. 실제로 무엇이 급전하고 있는지 확인한다.
   USB-C는 대시보드를 구동하지만 ASIC에는 급전할 수 없다.
   USB-C만 연결된 채굴기는 영원히 0 GH/s와 약 2 W를 보여준다.
   진짜 전원(DC 잭 / XT30)이 꽂혀 있고 끝까지 들어가 있는지,
   그리고 전압이 올바른지(5 V 대 12 V: 잘못 쓰면 보드가
   파괴된다) 확인할 것.

3. http:// 를 명시적으로 입력한다.
   브라우저는 조용히 https:// 로 바꾸고 실패한다.
   http://채굴기IP —— 접두사를 붙여서, 매번.

4. 2.4 GHz를 준다.
   이 무선 모듈들은 5 GHz를 결코 말하지 않는다. 메시
   라우터에서는 2.4 GHz 전용 SSID나 IoT 네트워크를 만들고
   WPA2-AES를 쓰며 AP 격리를 끈다.

5. 채굴기가 아니라 풀에 묻는다.
   풀 대시보드의 "마지막 승인 셰어 이후 경과 시간"이
   온라인 여부를 판별하는 유일하게 정직한 검사다.
   10분 초과 = 지금 이 순간 죽어 있다. 채굴기 화면이
   무슨 말을 하든 상관없다.

해결됐나요? 좋습니다, 탭을 닫으세요. 안 됐나요? 아래
분류가 60초 안에 당신의 장을 찾아줍니다.

문제를 빠르게 찾기

스무 개의 장은 확실히 많습니다. 자기 장으로 건너뛰는 방법이 셋 있습니다.

검색으로: 이 가이드의 모든 오류 문자열은 펌웨어가 출력하는 그대로 한 글자도 바꾸지 않고 적혀 있습니다. Ctrl+F(Mac은 Cmd+F)를 누르고 오류 메시지를 붙여 넣으면 바로 그 위에 내려앉습니다. 이것은 운이 아니라 설계상의 결정입니다.

증상으로:

읽는 방식으로: 다음 장에서 이 가이드를 초보자 경로와 전문가 경로로 나눕니다.

자신의 경로를 고르기

이 가이드는 매우 다른 두 종류의 독자를 위해 쓰였고, 같은 방식으로 읽어서는 안 됩니다.

첫 채굴기, 첫 문제인가요? 번호가 붙은 경로를 아무것도 건너뛰지 말고 따라가세요. 두 가지 안전 규칙, 내장 셀프 테스트, 60초 분류, 그리고 분류가 보내준 그 장만. 모든 코드 블록은 그대로 복사해 쓸 수 있고, 모를 만한 용어는 바로 아래 미니 용어집에 있습니다. 초보자 경로에는 케이스를 열거나 멀티미터를 가지고 있어야 하는 내용이 하나도 없습니다.

터미널과 테스터에 익숙한가요? 당신의 추월 차선은 이쪽입니다. 로그를 원격으로 가져오고 여러 대를 한꺼번에 점검하는 API 장, 오류 문자열에서 원인으로 곧장 건너뛰는 빨간 오류 줄 사전, 기종별 특성 표, 그리고 마지막의 전문 작업대 장. 회로도, 측정 지점 방법론, 보드 수준의 자료가 거기에 있습니다. PRO로 표시된 장은 회로도를 읽을 수 있고 통전 상태의 보드를 안전하게 프로빙할 수 있다는 것을 전제로 합니다.

이제 시작하는 사람을 위한 미니 용어집

열 개의 용어, 각각 십 초. 이걸로 가이드의 나머지가 두 배 빠르게 읽힙니다.

ASIC        채굴 칩 그 자체 —— 실제로 해시를 계산하는
            유일한 부품
ESP32       나머지 전부를 담당하는 작은 컨트롤러:
            WiFi, 대시보드, ASIC과의 통신
AxeOS       ESP32 위의 펌웨어 + 웹 대시보드
VCORE       ASIC 코어에 공급되는 약 1.0-1.3 V —— 입력
            5 V 또는 12 V에서 보드 위에서 만들어진다
VRM / TPS546  VCORE를 만들어내고, 결함 시 스스로 차단해
            칩을 보호하는 레귤레이터 회로
stratum     채굴기가 풀과 대화하는 데 쓰는 프로토콜
셰어        제출하는 작업 증명. 풀은 이것을 세어
            당신이 살아 있음을 안다
HW 오류율   칩이 "틀리게" 계산한 결과의 비율 ——
            가장 정직한 건강 지표(2% 미만 유지)
OTA         대시보드를 통한 "무선" 업데이트.
            USB를 통한 플래싱과 대비되는 개념
NVS         재플래싱을 살아남는 설정 저장 영역 ——
            공장 초기화가 존재하는 이유

무엇보다 먼저: 두 가지 안전 규칙과 내장 도구

보드를 죽이지 않기 위한 두 가지 규칙

규칙 하나: 전압을 절대 추측하지 마세요. 표준 단일 칩 Bitaxe는 5 V를, GT·Hex·NerdQaxe++·NerdOctaxe는 12 V를 씁니다. 두 계열의 DC 잭은 물리적으로 서로 꽂히며, 12 V 전원을 5 V 보드에 연결하면 1초도 안 되어 영구적으로 파괴됩니다. 연결할 때마다 커넥터 모양이 아니라 전원의 라벨을 읽으세요. 이 취미에서 가장 값비싼 단일 실수입니다.

규칙 둘: 커넥터가 뜨거우면 중단. 미지근한 정도라면 경고지만, 뜨겁거나 변색되었거나 플라스틱 냄새가 난다면 즉시 전원을 끄고 다음 통전 전에 케이블을 교체해야 합니다. 이 가이드의 다른 모든 것은 내일까지 기다릴 수 있습니다. 이것만은 안 됩니다.

내장 셀프 테스트 실행하기

AxeOS에는 대부분의 소유자가 존재조차 모르는 전원 투입 셀프 테스트가 들어 있습니다. 다섯 개의 서브시스템을 순서대로 검사하고 첫 번째로 실패한 항목을 화면에 표시합니다. 즉 고장 난 영역의 이름을 알려주는 무료 30초 하드웨어 진단입니다.

검사 대상(순서)             실패 시 화면에 표시되는 것
  입력 레일                   POWER FAIL
  코어 전압 레귤레이터        VCORE FAIL
  I2C 센서 버스               (테스트 중에 멈춤)
  팬 회전수 피드백            FAN FAIL
  ASIC 감지                   ASIC FAIL
  짧은 해시 버스트            HASHRATE FAIL

결과 읽는 법
  POWER / VCORE FAIL   -> 전원 문제 장으로. 이 테스트는
                          정격에서 10% 이상 벗어난 입력을
                          거부한다 —— 전원을 측정할 것.
  ASIC FAIL            -> ASIC 문제 장으로.
  FAN FAIL             -> 팬 미연결, 고착, 또는 회전수
                          신호선 단선.
  HASHRATE FAIL        -> 칩은 감지되었으나 계산하지 않음:
                          대개 전원이 아슬아슬하거나 설정
                          문제. 공장값으로 되돌릴 것.

셀프 테스트 자체가 멈추는 경우
  화면이 SELF TEST에서 30초 넘게 멈추거나 SELF TEST ->
  재부팅 무한 루프에 빠지는 경우: AxeOS v2.12 이상에서는
  SELF TEST 화면 동안 BOOT 버튼을 2초간 길게 눌러 건너뛰고
  대시보드로 들어갈 수 있다. 거기서 진단할 것. 플래싱 후의
  셀프 테스트 루프는 대개 보드에 맞지 않는 이미지를
  썼다는 뜻이다.

셀프 테스트는 첫 부팅 시 자동으로 실행되며 설정 화면에서 수동으로도 실행할 수 있습니다. 하드웨어에 무슨 일이 있은 뒤에는 반드시 돌려보세요. 운송 후, 방열판 재장착 후, 전원 교체 후. 로그를 하나도 열기 전에 “뭔가 이상하다”를 이름이 있는 서브시스템으로 바꿔줍니다.

화면이 말하고 있는 것

디스플레이가 있는 기종에서 OLED는 장식이 아니라 상태 계기입니다. 몇 초마다 정보 화면을 번갈아 보여주며, BOOT 버튼으로 수동으로 넘길 수 있고 타이머로 꺼진 화면을 깨울 수도 있습니다. 알아둘 상태는 부팅 화면(펌웨어가 살아 있음), 설정용 핫스팟 화면(미설정 또는 WiFi 자격 증명 분실), IP 주소 화면(대시보드로 가는 문), 위의 셀프 테스트와 FAIL 코드, 과열 경고, 그리고 언젠가 만나기를 바라는 블록 발견 애니메이션입니다. 화면이 어둡다는 것이 보드가 죽었다는 증거는 아닙니다. 단순히 화면 꺼짐 타이머가 작동한 것은 아닌지, 풀에 셰어가 계속 도착하고 있지는 않은지 확인하세요.

60초 분류

로그를 하나도 열기 전에 다섯 가지 질문에 답하세요. 이것으로 문제 공간 전체가 나뉩니다.

Q1  무엇이든 켜지는가? (LED, 화면, 팬)
      아니오 -> 전원 영역. 이동: 전원 문제.
      예     -> Q2

Q2  기기가 AxeOS 대시보드에 도달하거나 IP를 표시하는가?
      아니오 -> Q2a: 설정용 핫스팟을 내보내고 있는가?
                예     -> WiFi 영역. 이동: 네트워크 문제.
                아니오 -> 부팅 영역. 이동: 펌웨어 문제.
      예     -> Q3

Q3  대시보드의 해시레이트가 0보다 큰가?
      아니오 -> Q3a: 전원 결함, 과열 배너, 또는 ASIC 칩 0
                중 무엇이 표시되는가?
                전원 결함 -> 전원 문제
                과열      -> 발열 문제
                0 칩      -> ASIC 문제
      예     -> Q4

Q4  풀이 최근 10분 안에 승인된 셰어를 보여주는가?
      아니오 -> STRATUM 영역. 이동: 풀 문제.
      예     -> Q5

Q5  해시레이트, 오류율, 온도가 있어야 할 값인가?
      아니오 -> 발열 문제, 또는 오버클럭 실패.
      예     -> 아무것도 고장 나지 않았다. 탭을 닫아도 된다.

Q4가 묻는 대상이 기기가 아니라 풀이라는 점에 주목하세요. 가정용 채굴에서 가장 흔한 헛수고는, 화면상으로는 완벽해 보이지만 풀이 한 시간째 그 목소리를 듣지 못한 채굴기를 디버깅하는 것입니다. 기기와 풀은 각각 그림의 절반씩만 보고 있으며, 이 가이드는 이 비대칭성으로 몇 번이고 되돌아옵니다.

로그 읽는 법

로그를 읽을 수 있으면 이 가이드의 다른 모든 것이 빨라지므로 이 장을 앞에 두었습니다. 로그 창구는 두 개이며 각각 다른 질문에 답합니다.

AxeOS 웹 로그

채굴기의 IP 주소로 대시보드를 열고 로그 화면을 찾으세요. 실행 중인 로그를 실시간으로 보여줍니다. stratum 트래픽, 셰어 제출, 난이도 변경, 온도 이벤트 같은 것들입니다. 기기가 정상적으로 부팅되었고 질문이 “지금 무엇을 하고 있는가”일 때 올바른 도구입니다. 한계는 둘입니다. 네트워크가 올라온 뒤에 시작하므로 부팅 실패를 보여줄 수 없고, 웹 서버와 함께 죽으므로 크래시를 보여줄 수 없습니다.

시리얼 콘솔: 진실

부팅, 크래시, ASIC 감지, WiFi 접속과 관련된 일이라면 필요한 것은 시리얼 콘솔입니다. 개발자들이 읽는 것과 같은 출력이며 맨 첫 번째 명령부터 시작합니다.

1. USB-C 데이터 케이블(충전 전용이 아닌 것)로 채굴기와
   컴퓨터를 연결한다. 일부 Bitaxe 보드에서는 네이티브
   USB-C 대 USB-C 연결이 협상에 실패한다. 그럴 때는
   USB-A에서 USB-C로 가는 케이블이나 어댑터를 쓴다.
   이것이 기존 방식의 5V를 강제한다.

2. 115200 보드레이트, 8N1 시리얼 터미널을 연다:

   Windows:  PuTTY -> Serial -> COMx -> 115200
   Linux:    sudo minicom -D /dev/ttyACM0 -b 115200
             (또는: screen /dev/ttyACM0 115200)
   macOS:    screen /dev/tty.usbmodem* 115200

3. 보드의 RST 버튼을 누른다(또는 전원을 다시 꽂는다).
   전체 부팅 로그가 처음부터 흘러간다.

ESP-IDF 로그 줄에는 심각도를 나타내는 문자가 붙습니다. I는 정보, W는 경고, E는 오류입니다. 대부분의 터미널은 E 줄을 빨간색으로 표시합니다. 건강한 부팅에는 E 줄이 0개입니다. 로그 읽기의 기술은 이 한 문장에 담깁니다. 부팅을 훑어 내려가 첫 번째 E를 찾고, 이 가이드 끝의 사전에서 찾아보라는 것. 중요한 것은 첫 번째 오류입니다. 뒤따르는 오류들은 대개 첫 번째로 인한 연쇄 피해이기 때문입니다.

건강한 부팅은 이렇게 생겼습니다

주석을 달고 줄인 것입니다. 당신 것은 세부에서 다르겠지만 같은 순서로 같은 이정표를 지나야 합니다.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- 리셋 사유. POWERON은 정상. 여기서 RTC_WDT나
           BROWNOUT 리셋이 반복된다면 그것이 첫 번째
           경보 신호다.

I (xx) main: Found device config: <당신 보드의 모델>
        <- 펌웨어가 보드를 식별했다. 여기서 모델명이
           틀렸다면 잘못된 펌웨어 이미지를 쓴 것이다.

I (xx) TPS546: Found TPS546D24A          (TPS 탑재 보드)
I (xx) Power: VCORE set to 1150 mV
        <- 코어 레귤레이터가 I2C로 응답했고 ASIC 레일이
           올라왔다. 이 블록이 없거나 오류를 내면 그 뒤의
           어떤 것도 동작할 수 없다.

I (xx) bm13xx: Found 1 chip(s)
        <- 결정적인 줄. 이 숫자는 당신 보드의 칩 수와
           일치해야 한다: 단일 칩이면 1, GT는 2,
           NerdQaxe는 4, Hex는 6, NerdOctaxe는 8.

I (xx) wifi: connected, IP: 192.168.x.x
        <- 네트워크 확립. 접속 실패는 여기에 사유 코드를
           출력한다(사전은 아래).

I (xx) stratum_task: Connected to pool ...
I (xx) stratum_task: mining.subscribe / authorize OK
I (xx) stratum_task: Set difficulty to ...
I (xx) create_jobs_task: New Work: ...
        <- 풀이 로그인을 받아들이고 작업을 보내왔다.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- ASIC이 결과를 돌려주고 있다. 1~2분 안에 풀
           난이도를 넘는 셰어가 제출되고 승인되는 것이
           보여야 한다.

이정표의 순서를 외우세요. 리셋 사유 → 보드 설정 → 레귤레이터 → 칩 수 → WiFi → stratum → nonce. 가장 먼저 실패하는 이정표가 당신에게 필요한 장의 이름입니다.

전원 문제: 모든 고장의 첫 번째 원인

가정용 채굴기의 고장에 순위가 있다면 전원이 상위 세 자리를 독차지할 것입니다. 이 보드들은 소비자용 전원에서 소비자용 커넥터를 거쳐 3 nm와 5 nm 실리콘을 높은 전류로 구동하며, 여유는 아주 얇습니다.

자신의 급전 구조 알기

단일 칩 Bitaxe(Max/Ultra/Supra/Gamma)
  입력:       5 V, DC 잭(5.5x2.1mm) 또는 USB-C
  전류:       Gamma 초기 상태에서 최대 약 5 A, OC 시 더 높음
  레귤레이터: TPS546D24A 디지털 벅(구형 보드는 DS4432U
              DAC + INA260 모니터). 5V를 매우 큰 전류로
              약 1.1-1.3V의 ASIC 코어 전압까지 낮춘다
  동작 창:    레귤레이터는 약 4.8 V에서 켜지고 약 4.5 V
              아래에서 차단된다

12 V 계열(GT, Hex, NerdQaxe++, NerdOctaxe)
  입력:       12 V, XT30 커넥터 또는 DC 잭
  전류:       NerdQaxe++는 전부하에서 약 8+ A, Octaxe는 그 이상
  위험:       커넥터 발열, 부하 시 전압 강하

중요한 사실: 현행 Bitaxe 보드의 USB-C는 ESP32와 플래싱
전용이다. ASIC에는 급전할 수 없다. USB-C만으로 동작하는
보드는 부팅되고 대시보드를 보여주며, 소비 전력 약 2 W에서
정확히 0 GH/s의 해시레이트를 낸다. 이것은 고장 난
레귤레이터를 정확히 흉내 내기 때문에 커뮤니티 전체에서
매주 몇 시간씩을 낭비시키고 있다.

Power Fault Detected: 실제로 일어난 일

TPS546 레귤레이터는 네 가지 보호를 감시합니다. 과전류, 과전압, 저전압, 과온도입니다. 어느 하나가 작동하면 레귤레이터는 차단 상태를 래치하고 AxeOS가 전원 결함 배너를 표시합니다. ASIC은 레일을 잃지만 별도로 급전되는 ESP32가 화면을 계속 살려둡니다. 해결책을 좌우하는 사실이 둘 있습니다.

• 래치는 소프트웨어 재시작을 살아남습니다. 결함 상태는 레귤레이터 자신의 상태 레지스터에, 입력 전압이 물리적으로 제거될 때까지 보존됩니다. 웹 화면에서의 재시작, restart API 호출, ESP32 리셋 버튼 누르기 그 어느 것도 이것을 지우지 않습니다. 이것은 버그가 아니라 문서화된 동작이며, GitHub에 한 부류를 이루는 issue 무리가 존재하는 이유이기도 합니다. 5 W를 소비하며 0 GH/s에서 멈춘 BM1370 보드에서 restart 엔드포인트는 아무것도 고치지 못하는데 전원을 한 번 뽑았다 꽂으면 전부 해결된다는 내용입니다.
• 작동은 증상이고 원인은 상류에 있습니다. 레귤레이터가 지키고 있는 것은 그 주변 보드 전체보다 비싼 칩입니다. 반복해서 작동하는 경우의 압도적 다수는 레귤레이터가 아니라 입력 전원으로 거슬러 올라갑니다.

해결 절차를 순서대로:

1. 콜드 사이클. 전원 커넥터 자체를 뽑는다(벽 스위치가
   아니라). 꼬박 10초를 센다. 일부 보드는 벌크 커패시터가
   방전되고 ESP32의 브라운아웃 유지 상태가 지워지기까지
   60초가 필요하다. 다시 꽂는다. 이것만으로 단발성 결함의
   대부분은 해결된다.

2. USB-C를 뺀다. USB-C 포트에 무언가 꽂혀 있다면 빼고,
   진짜 전원(DC 잭 / XT30)이 꽂혀 있는지 확인한다.
   위에서 설명한 USB-C 함정을 배제할 것.

3. 부하를 걸고 측정한다. 테스터를 직류에 맞추고,
   채굴기가 해시하고 있는 도중에 입력 커넥터에서 측정:
     5 V 보드:  4.9-5.3 V가 유지되어야 한다.
                4.8 V 아래 = 전원이 원인.
     12 V 보드: 11.8-12.2 V가 유지되어야 한다.
                11.4 V 아래 = 전원이 원인.
   무부하 측정은 아무것도 증명하지 못한다. 저품질 전원은
   무부하에서 완벽한 5.0 V를 보여주다가 부하가 걸리면
   4.4 V까지 떨어진다.

4. 경로를 배제한다. 전원을 벽 콘센트에 직접 꽂는다.
   멀티탭도 연장선도 줄줄이 연결도 안 된다. 품질이 낮은
   멀티탭은 측정 가능한 전압 강하를 만든다. DC 잭을
   흔들어 본다: 화면이 깜빡이면 잭이나 케이블이 마모된 것.

5. 전원을 업그레이드한다. 정직한 최소 사양:
     5 V 단일 칩 보드:    양질의 5 V / 5 A 전용 전원
     NerdQaxe++급 12 V:   12 V / 10 A(120 W) 이상
   스마트폰 충전기와 범용 어댑터는 이 가이드 전체에서
   가장 흔한 근본 원인이다.

XT30에 대한 경고

12 V 계열은 8암페어 이상을 하나의 XT30에 흘립니다. 커넥터 자체는 그 정격으로 만들어졌지만, 그 뒤에서 손으로 납땜된 리드선은 그렇지 않은 경우가 많습니다. 핀의 변색, 만져서 미지근한 커넥터, 냉납, 느슨한 압착을 점검하세요. 8 A에서의 고저항 접합부는 발열하고, 산화되고, 저항이 더 오르고, 더 발열합니다. 가정용 채굴에서 플라스틱이 녹으며 끝나는 유일한 고장 방식이 이것입니다. 커넥터가 한 번이라도 변색될 만큼 뜨거웠다면 케이블을 교체하세요. 재사용하지 마세요. 전원 오류와 Guru Meditation 코드를 내며 멈추는 NerdQaxe는 바로 이 부하에서 떨어지는 레일로 거슬러 올라갑니다.

브라운아웃: 크래시가 아닌 크래시

ESP32에는 하드웨어 브라운아웃 검출기가 있습니다. 3.3 V 레일이 떨어지면 Brownout detector was triggered를 출력하고 재부팅합니다. 몇 분마다 재부팅되는 채굴기, 특히 ASIC이 전부하로 올라갈 때 재부팅되는 것은 거의 확실히 펌웨어 문제가 아닙니다. 최대 소비 순간에 급전이 무너지고 있는 것입니다. 해결책은 위의 3번부터 5번입니다. 브라운아웃 루프를 두고 펌웨어를 쫓아다니지 마세요.

ASIC 문제: 칩이 응답하지 않음

부팅 로그에서 봐야 할 줄은 칩 수입니다. 펌웨어는 UART로 ASIC 체인을 열거하고 몇 개의 칩이 응답했는지 출력합니다. 당신 보드의 온전한 수가 아닌 모든 경우가 이 장의 이야기입니다.

칩이 0개 감지됨

대시보드의 ASIC 수가 0으로 나오거나 로그에 초기화 실패가 뜹니다. 관측되는 빈도순으로 원인을 들면 이렇습니다.

1. 래치된 레귤레이터, 또는 유지된 브라운아웃 상태. 코어 전압이 없는 칩은 열거되지 않습니다. 다른 무엇보다 먼저 60초 완전 콜드 방전을 하세요. 메인 전원, USB-C, 모든 부속품을 빼고 꼬박 1분을 기다린 뒤 다시 통전합니다. 이것만으로도 무시할 수 없는 비율의 사례가 해결됩니다.
2. 잘못된 펌웨어 이미지. 다른 보드의 이미지를 단 한 번이라도 쓰면 비휘발성 메모리에 잘못된 기기 설정이 남아 이후의 재플래싱을 살아남을 수 있습니다. 부팅 로그의 모델 줄이 실제 보드와 일치하지 않으면 완전한 공장 초기화를 한 뒤 올바른 이미지를 쓰세요. BM1370 보드에 BM1366 이미지를 넣으면 칩은 영원히 발견되지 않습니다.
3. 물리적 사건. 전형적인 시간 순서는 이렇습니다. 옮겼다, 떨어뜨렸다, 배송했다, 또는 방열판을 다시 조였다. 그리고 두 번 다시 해시하지 않게 되었다. ASIC 아래에는 BGA 솔더볼 배열이 있고, 휨이 그것을 깨뜨립니다. 방열판의 장착 압력이 고르지 않아도 같은 일이 벌어집니다. 시간 순서가 맞는다면 이것은 설정 문제가 아니라 작업대에서의 수리(리플로)입니다.
4. 초기 불량. 한 번도 해시한 적 없는 새 제품은 제조 시 냉납일 확률이 불균형하게 높습니다. 주말을 소프트웨어에 쓰지 마세요. 콜드 방전과 펌웨어 확인만 끝내고 보증을 쓰세요.

칩 수가 모자람: 멀티칩 특유의 징후

Hex가 6개 중 3개, NerdQaxe가 4개 중 2개, GT가 2개 중 1개로 보고하는 경우입니다. 멀티칩 보드는 ASIC을 하나의 체인으로 열거하므로 죽었거나 끊긴 칩이 하나 있으면 체인의 그 지점에서 감지가 끊깁니다. 즉 그 숫자가 단선의 대략적인 위치를 알려줍니다. 4칩 보드가 2를 표시한다면 문제는 3번째 칩에 있습니다. 원인은 위와 같고(전원 여유, 갈라진 납땜) 여기에 멀티칩 특유의 것이 하나 더해집니다. 체인 안의 약한 칩이 높은 주파수에서만 탈락하는 경우입니다. 공장 출하 주파수에서는 온전한 수로 돌아오는데 오버클럭하면 칩이 사라진다면, 당신은 실리콘 복권에서 뽑은 가장 약한 다이를 찾은 것이며 그 한계가 보드 전체의 한계가 됩니다.

I2C 오류: 채굴기가 아니라 센서 버스

헷갈리는 부류의 증상이 있습니다. 채굴기는 정상적으로 해시하는데 Power, ASIC Temp, Input Voltage가 대시나 null이나 0으로 표시되고 로그에는 I2C 송수신 오류나 타임아웃이 뜨는 것입니다. 해시 경로(ASIC으로 가는 UART)와 텔레메트리 경로(레귤레이터의 PMBus, 온도 센서, 전류 모니터로 가는 I2C)는 별개의 버스입니다. 한쪽이 죽어도 다른 쪽은 계속 돌아갑니다. 알려진 유발 요인은 AxeOS v2.13/v2.14 부근의 펌웨어 퇴행 구간으로, 일부 개체에서 센서 읽기 경로가 조용히 실패하는 것입니다. I2C 커넥터를 공유하는 모든 부속품도 원인이 됩니다. 나중에 붙인 OLED나 접촉이 나쁜 외부 센서가 온보드 센서까지 버스를 막아버릴 수 있습니다. 기기를 출하 시 구성으로 되돌리고 콜드 사이클을 한 뒤, 펌웨어 퇴행 구간이 원인이라면 앞으로 나아가거나 한 버전 되돌리세요.

위험한 부작용이 있습니다. 온도 피드백이 없으면 팬 커브가 동작하지 못해 팬이 하나의 회전수에 고정됩니다. 텔레메트리가 죽었다면 발열 보호도 죽은 것으로 취급하고, 고칠 때까지 무인으로 돌리지 마세요.

발열 문제: 열은 사건이 아니라 예산이다

의미 있는 수치

ASIC 코어 온도  목표:      55-62 C 유지
                우려:      65 C 초과가 상시화
                차단:      약 75 C -> Overheat 모드

VREG 온도       부하 시 코어보다 10-15 C 높게 동작한다.
                BM1370/BM1373 보드에서는 코어가 아니라
                이쪽이 제한 센서인 경우가 많다

Overheat 모드   해시가 멈추고 팬은 100%, 화면은 살아 있다.
                온도가 약 65 C까지 내려가면 히스테리시스와
                함께 해제된다

패턴으로 진단하기

차가운 상태에서 곧바로 과열 —— 장착 문제입니다. 방열판이 닿지 않고 있습니다. 서멀 패드의 누락이나 찢어짐, 마른 혹은 바르지 않은 그리스, 조임 토크의 불균일, 운송 중에 풀린 방열판 같은 것들입니다. 접촉이 없는 칩은 실온에서 차단 온도까지 몇 초 만에 도달합니다. 다시 장착하고, 좋은 그리스를 쌀알 한 알만큼 바르고, 나사를 대각선으로 고르게 조이세요.

10분에서 30분 뒤에 과열 —— 방열 능력 문제입니다. 접촉은 좋지만 발생하는 열을 버리는 속도가 따라가지 못합니다. 원인은 겹칩니다. 실온이 약 27 C를 넘음, 캐비닛이나 서랍이나 밀폐 케이스 안에 있음, 흡기나 배기가 막힘, 핀에 먼지가 펠트처럼 얹힘, 또는 냉각계가 상정하지 않은 오버클럭을 함. 양쪽에 10 cm의 공간을 확보하고 핀을 청소하세요. 주파수를 바꾼 직후부터 시작되었다면 그 변경이 지나쳤던 것입니다.

몇 주에 걸쳐 천천히 상승 —— 유지보수 문제입니다. 설정은 그대로인데 온도가 한 도씩 기어오른다면 먼지 축적이나 서멀 그리스의 건조입니다. 이 보드들에서 그리스는 소모품이며 6개월에서 12개월마다 다시 바르는 것이 정상입니다.

펌웨어 업데이트 후의 과열 —— 커브 문제입니다. 팬과 발열 커브는 버전 사이에서 바뀝니다. v2.11 부근의 문서화된 사례에서는 기본 동작이 옮겨간 결과, 공장 설정 그대로 몇 도 더 뜨겁고 약간 느리게 동작하게 되었습니다. 릴리스 노트를 읽고 팬 회전수를 수동으로 한 단계 올리거나, 펌웨어가 PID 제어를 제공한다면 목표 온도를 조정하세요.

팬 그 자체

어떤 온도에서도 0 RPM을 보고하는 팬은 연결되지 않았거나, 케이블에 걸려 고착되었거나, 고장 난 것입니다. 항상 100%로 울부짖는 팬은 정말로 칩이 뜨겁거나(위 참조), 온도 텔레메트리가 죽어서 커브가 눈먼 채로 제어하고 있거나(I2C 장 참조) 둘 중 하나입니다. 40 mm와 60 mm 교체용 팬은 저렴하고, 고품질 저소음 모델(커뮤니티의 단골 선택은 Noctua)은 소음을 40 dB 아래로 낮춥니다. 이 기기들에서 가성비가 가장 좋은 하드웨어 개선입니다.

네트워크 문제: ESP32가 보는 WiFi 세계

이 기계들에 들어 있는 무선 모듈은 2.4 GHz만 말합니다. 5 GHz도 6 GHz도 아니고, 예외도 없으며, 펌웨어로 고칠 방법도 없습니다. 설치 실패의 매우 큰 비율이 이 한 문장과 현대 라우터의 동작 사이의 충돌로 귀결됩니다.

메시 라우터 문제

현대의 메시 시스템은 하나의 통합 SSID를 내보내고 클라이언트를 밴드 사이로 유도합니다. ESP32는 5 GHz 쪽에 참여할 수 없고, 밴드 스티어링은 2.4 GHz에 자리 잡는 것을 방해할 수 있습니다. 확실한 대처법은 다음과 같으며 대부분의 라우터는 적어도 하나를 지원합니다.

방법 A  2.4 GHz 전용 SSID를 만든다(최선)
방법 B  라우터의 "IoT 네트워크" 기능을 쓴다 —— 여러
        제조사가 바로 이런 기기를 위해 넣어두었다
방법 C  밴드 스티어링 / "smart connect"를 끄고 밴드를
        별도의 SSID로 보이게 한다

그다음 2.4 GHz SSID 쪽을 확인:
  보안         WPA2-Personal, AES만(TKIP는 불가.
               WPA3 전용 네트워크는 실패한다)
  채널         혼잡한 환경에서는 1, 6, 11로 고정. Auto 불가
  채널 폭      20 MHz
  AP 격리      끔 <- 켜져 있으면 WiFi는 연결되는데
               대시보드에 LAN에서 접근할 수 없어,
               기기가 죽은 것과 똑같이 보인다
  MAC 필터     끔, 또는 채굴기의 MAC을 등록

시리얼 로그에서 WiFi 실패 읽기

시리얼 콘솔은 접속에 실패할 때마다 끊김 사유를 출력하며, 그 사유가 곧 해결책의 이름입니다.

AUTH_EXPIRE / auth failed      비밀번호(PSK)가 틀렸다.
                               다시 입력할 것. 스마트폰에서
                               복사했다면 조판용 따옴표에
                               주의.
NO_AP_FOUND                    SSID가 2.4 GHz에서 보이지 않음:
                               밴드 스티어링, SSID 숨김,
                               전파 범위 밖, 또는 5 GHz 전용.
beacon timeout                 신호가 너무 약하거나 채널 혼잡.
                               기기를 옮기거나 채널을 고정.
ASSOC_TOOMANY                  라우터의 클라이언트 수 한계 도달.
Brownout detector triggered    이건 WiFi 문제가 전혀 아니다:
                               접속 시 무선 모듈의 소비 전류
                               피크가 약한 전원을 무너뜨리고
                               있다. 고쳐야 할 것은 전원이지
                               네트워크가 아니다.

마지막 항목은 강조해 둘 가치가 있습니다. WiFi 송신은 ESP32가 만들어내는 최대의 순간 부하 피크입니다. 유휴 상태라면 겨우 버티는 아슬아슬한 전원이 접속하는 순간에 죽습니다. 즉 “WiFi 연결 시 크래시하는” 개체는 대개 네트워크의 옷을 입은 전원 문제입니다.

WiFi 오류가 없는데 접근이 안 되는 경우

라우터의 두 가지 보안 기능은 특별히 언급할 가치가 있습니다. 설계상 채굴기를 차단하기 때문입니다. ASUS의 AiProtection과 일부 TP-Link 기종의 동등한 기능은 stratum 트래픽을 의심스러운 것으로 판정해 조용히 버립니다. 채굴기는 완벽하게 WiFi에 참여하고, 그다음 어떤 풀에도 도달하지 못합니다. WiFi에는 연결되는데 풀 연결이 전부 실패하고 같은 풀이 스마트폰 테더링에서는 동작한다면, 다른 무엇을 건드리기 전에 라우터의 해당 보호 기능을 끄거나 채굴기를 화이트리스트에 넣으세요.

그리고 끝없이 오경보를 만들어내는 브라우저의 버릇이 하나 있습니다. AxeOS는 80번 포트에서 평범한 HTTP를 제공합니다. 현대의 브라우저는 접두사 없는 주소를 조용히 HTTPS로 바꾸고, 그것이 실패하고, 채굴기가 죽은 것처럼 보입니다. 접두사를 명시적으로 입력하세요. IP 앞에 http://를, 매번. 그래도 실패하면 다른 브라우저를 시도하고 로컬 주소에 대해 광고 차단기를 끄세요.

채굴기에 IP는 있는데 대시보드가 열리지 않는다면 AP 격리(위), 라우터 클라이언트 목록의 버릇, 또는 mDNS입니다. 기기는 .local 호스트명으로 자신을 알립니다. 여러 개체가 같은 호스트명을 쓰면 현대 펌웨어가 MAC 기반 접미사를 자동으로 붙이지만, 컴퓨터 쪽의 오래된 mDNS 캐시가 여전히 엉뚱한 개체를 가리킬 수 있습니다. 헷갈리면 라우터의 DHCP 테이블에서 날것의 IP를 쓰고 각 개체에 서로 다른 호스트명을 주세요.

Stratum과 풀 문제: 라스트 마일

기기는 부팅되었고 해시하고 있으며, 진실이 결정되는 곳은 풀입니다. 이 장에서는 채굴기 쪽 시각과 풀 쪽 시각을 함께 읽어야 합니다.

연결 거부 또는 도달 불가

이 순서로 확인한다:
1. URL 정확성: stratum+tcp://호스트:포트 —— https:// 불가,
               끝의 슬래시 불가, 포트는 필수이며 정확해야 함
2. DNS:        같은 LAN의 다른 기기가 그 호스트를 해석하는가?
               일부 통신사 라우터와 DNS 필터(Pi-hole 같은
               차단기 포함)는 채굴 관련 도메인을 조용히
               삼켜버린다.
3. 포트:       일부 네트워크는 흔치 않은 아웃바운드 포트를
               막는다. 스마트폰 테더링으로 시험해 볼 것:
               거기서 연결되면 집 네트워크가 차단하는 것이다.
4. 리전:       풀의 다른 리전 엔드포인트를 시도한다.
               단일 리전의 장애를 보고 있을 뿐일 수도 있다.

authorize 실패

풀이 로그인을 거부했습니다. 솔로 풀에서 사용자 이름은 지갑 주소와 워커 이름의 조합이며, 주소가 곧 정체성의 전부입니다. 잘못 입력할 “계정”이라는 것이 존재하지 않습니다. 원인으로는 주소의 오타(한 글자면 충분합니다), 잘못된 체인의 주소(아래 참조), 공백이나 특수 문자가 들어간 워커 이름, 또는 풀이 비어 있지 않기를 기대하는 비밀번호 필드(x를 넣으세요) 등이 있습니다.

잘못된 체인의 주소: 조용한 살인자

멀티체인 SHA-256 채굴에서 가장 해로운 설정 실수이며, 두 가지 방식으로 실패할 수 있습니다.

• 시끄러운 실패: 풀이 체인별로 주소 형식을 검증해 authorize나 모든 셰어를 거부합니다. 짜증나지만 안전합니다. 몇 분 안에 알아챌 수 있습니다.
• 조용한 실패: 여러 체인에서 형식상 유효한 주소, 또는 깊이 검증하지 않는 풀이 하루 종일 당신의 셰어를 받아들이고, 그런 다음 지급이 당신에게 도달하지 않습니다. 비수탁형 솔로 풀에서 블록 보상은 당신이 설정한 주소 문자열로 코인베이스 직접 지급됩니다. 쓸 수 없는 주소로 지급된 코인베이스를 되돌릴 수 있는 지원 창구는 존재하지 않습니다.

규칙은 이렇습니다. 주소는 당신이 향하고 있는 체인의 네이티브 주소여야 합니다. 그 체인의 지갑에서 생성하고 검증한 것을 쓰세요. 같은 물리 채굴기를 체인 사이에서 돌려 쓴다면 “체인 → 주소” 대응표를 적어 두고, stratum URL을 바꿀 때마다 매번 사용자 이름 필드를 다시 확인하세요. 이것은 이 장의 다른 모든 조언을 합친 것보다 가치가 있습니다.

거부된 셰어: 거부 사유 읽기

거부는 하나의 문제가 아닙니다. 로그의 사유 문자열이 네 가지 중 어떤 문제인지 알려줍니다.

"job not found" / stale       풀이 이미 교체한 job에 대해
  새 블록 직후에 작은          작업을 제출했다: 블록이 바뀌는
  덩어리로 나온다              시점에는 정상이다. 전체의
                              ~1-2% 미만이면 무시해도 된다.
                              지속적으로 그 이상이면 네트워크
                              지연이나 WiFi 패킷 손실이다.
                              RSSI를 확인하고 더 가까운 풀
                              리전을 시도할 것.

"above target" /              셰어가 풀이 배정한 난이도에
"low difficulty share"        미치지 못한다. 지속되는 경우:
                              난이도 변경 후의 어긋남, 또는
                              결과를 망가뜨리는 하드웨어 오류.
                              HW 오류율을 확인할 것.

"duplicate"                   같은 nonce가 두 번 제출되었다.
                              가끔이라면 무해한 재전송의 산물.
                              연속으로 나온다면 알려진 고장
                              상태로, ASIC이 하나의 nonce에서
                              루프를 돌고 있다. 칩이 걸린 것.
                              전원을 다시 넣고, 현재 주파수에서
                              재발하면 오버클럭을 낮출 것.

전부 거부된다                 운이 나쁜 게 아니라 설정이다:
                              잘못된 체인의 주소, 형식이 잘못된
                              워커 이름, 또는 잘못된 포트
                              (예: 대형 ASIC용 고난이도 포트).

하드웨어 오류율: 정직한 숫자

대시보드의 해시레이트는 주장이고 하드웨어 오류율은 자백입니다. ASIC이 돌려줬지만 검증을 통과하지 못한 결과를 센 것입니다. 2퍼센트 미만이면 건강합니다. 온도 상승과 함께 오류율이 오른다면 발열 문제이고, 온도가 일정한데 설정 변경 후 오류율이 오른다면 주파수와 전압의 조합이 그 칩의 실리콘 한계를 넘은 것입니다. 오류율 5퍼센트인 칩은 그럴듯한 해시레이트를 표시하면서, 실효 해시레이트는 조용히 주파수를 낮췄을 때보다 못한 수준까지 떨어져 있을 수 있습니다. 튜닝할 때는 시간당 승인 셰어 수를 최적화 목표로 삼으세요. 대시보드의 숫자는 결코 목표로 삼지 마세요. 전체 방법론은 BM1373 레퍼런스의 튜닝 장에 있고, 셰어 난이도가 무엇을 뜻하는지에 대한 배경은 best share 해설에 있습니다.

”채굴기는 해시 중이라는데 풀에는 아무것도 없다”

모든 커뮤니티에서 가장 많이 올라오는 증상이므로 해결까지의 경로를 통째로 적어 둡니다.

1. 풀 쪽, 마지막 승인 셰어 이후 경과 시간:
   10분 초과 = 연결은 "지금" 죽어 있다. 채굴기 화면이 무슨
   말을 하든 상관없다. 대시보드의 평균값은 약 한 시간에
   걸쳐 감쇠하며 최근의 끊김을 가린다. "해시레이트가 0보다
   크다"는 온라인 검사가 아니다. "마지막 셰어가 최근"이
   검사다.

2. 채굴기 쪽, 실시간 로그:
   셰어가 "제출"되고 있는가? ASIC이 nonce를 찾고 있는데
   아무것도 제출되지 않는다면 stratum 소켓이 멈춘 것이다
   —— 채굴기를 재시작할 것.
   제출이 "오류"를 반환하는가? 거부 사유 표를 읽을 것.

3. 동일성 확인: 지금 보고 있는 풀 대시보드가 채굴기에
   설정된 것과 같은 지갑 주소, 그리고 같은 코인으로
   필터링되어 있는가? 놀랄 만큼 많은 경우가, 채굴기는
   BCH를 향하고 있는데 BTC 대시보드를 열어두었거나,
   어제의 테스트 주소 통계 페이지를 보고 있었다는 것이다.

4. 폴백: 예비 풀이 설정되어 있고 채굴기가 조용히 그쪽으로
   넘어가 있지는 않은가? 당신의 해시레이트는 "다른" 풀에
   도착하고 있을 수 있다. 그쪽 통계를 확인할 것.

폴백은 반드시 설정하세요

AxeOS 계열의 모든 기기는 예비 풀을 지원합니다. 폴백이 없는 채굴기가 새벽 2시에 stratum 소켓을 잃으면 당신이 알아챌 때까지 아무것도 하지 않습니다. 그리고 대시보드의 감쇠해 가는 평균값이 늦게 알아차리도록 확실히 만들어 줍니다. 폴백에는 같은 풀의 다른 리전을 설정하세요. 그러면 리전 단위 장애로 기계가 멈추는 일은 결코 없습니다. 각 체인의 리전별 호스트와 포트는 연결 페이지에 있습니다.

펌웨어 문제: 플래싱, 벽돌화, 복구

두 파일 구성의 OTA와 “반벽돌”

AxeOS 업데이트는 두 개의 산출물로 구성됩니다. 펌웨어 바이너리와 웹 인터페이스 이미지(www.bin)입니다. 문서화된 고장 방식 하나가 OTA가 www.bin 단계에서 멈춰 펌웨어와 인터페이스가 어긋나는 것입니다. 기기는 부팅되고 채굴도 하지만 대시보드가 백지이거나 깨져 있습니다. 이것은 벽돌화가 아닙니다. 복구용 URL로 곧장 접속하세요.

http://<채굴기ip>/recovery

그리고 웹 이미지를 다시 업로드합니다. 업데이트 실패 후 아예 부팅되지 않는다면, USB 웹 플래셔(Chrome이나 Edge, USB-C 데이터 케이블)가 공장 이미지 전체를 다시 써서 사실상 모든 소프트 벽돌을 구해냅니다. 세 가지 규칙이 플래싱을 무서운 일에서 지루한 일로 바꿔줍니다.

• 이미지를 보드에 정확히, 리비전 단위까지 맞추세요. 리비전 번호는 보드 자체에 인쇄되어 있고 AxeOS의 시스템 영역에도 표시됩니다. Supra 401에는 401 이미지가 필요하지 402가 아닙니다. 릴리스 페이지의 두 가지 파일을 이해하세요. 완전판 esp-miner-factory-REV-vX.X.X.bin(부트로더 + 파티션 + 인터페이스 + 펌웨어. USB 플래싱과 완전 복구용)과 더 작은 esp-miner.bin(펌웨어만. 대시보드를 통한 OTA용)입니다. 한쪽을 다른 쪽의 자리에 쓰는 것이 전형적인 반벽돌 레시피입니다. Gamma 이미지는 Gamma에, Ultra는 Ultra에. 잘못된 이미지는 NVS에 잘못된 기기 설정을 남겨 일반적인 재플래싱을 살아남을 수 있습니다. 치료법은 공장 초기화와 올바른 이미지의 조합입니다.
• 전파가 아슬아슬하거나 전원이 아슬아슬한 상태에서 WiFi를 통한 플래싱을 절대 하지 마세요. www.bin 단계에서 멈추는 현상은 바로 이 두 가지와 상관관계가 있습니다.
• 되돌아갈 버전을 파악해 두세요. 퇴행은 일어납니다. v2.13/v2.14 부근의 텔레메트리 상실 구간, 기기가 더 뜨겁게 동작하게 만든 v2.11 부근의 팬 커브 변경, 일부 하드웨어 리비전에서 사용자가 다운그레이드할 때까지 멈춰 있던 v2.4.3 부근의 업데이트 경로 등입니다. 업데이트 전에 현재 버전을 적어 두세요. 새 버전의 거동이 나쁘면 이전 버전은 프로젝트 릴리스 페이지에서 웹 플래싱 한 번 거리에 있습니다.

크래시 루프: Guru Meditation 읽기

Guru Meditation Error는 ESP32의 커널 패닉입니다. 괄호 안의 단어가 단서입니다.

Guru Meditation Error: Core X panic'ed (사유)

LoadProhibited /       펌웨어 버그가 잘못된 메모리를
StoreProhibited        건드리고 있다: 버전을 적고, issue
                       트래커를 확인하고, 한 버전 되돌린다
IllegalInstruction     플래시 손상 또는 스택 덮어쓰기:
                       USB를 통해 완전히 재플래싱한다
Cache error /          대개 PSRAM 문제에 뒤이어 나온다
DoubleException        (아래 참조)
Interrupt wdt timeout  태스크가 멈춰 있다 —— 네트워크
                       관련인 경우가 많다. 자기 버전의
                       알려진 issue를 찾아볼 것

단발성 패닉은 무시해도 됩니다. 루프라면 매번 같은 사유인지(펌웨어나 하드웨어 결함. 표에 따라 대처), 아니면 브라운아웃 메시지가 섞여 있는지(그렇다면 전원 문제입니다. 패닉 읽기를 그만두고 전원을 고치러 가세요)를 판별하세요.

PSRAM 결함: Nerd 계열 특유의 이야기

NerdQaxe, NerdOctaxe, 그리고 ESP32-S3-WROOM-1 모듈을 쓰는 다른 보드들은 외부 PSRAM을 탑재합니다. 부팅 배너에 PSRAM ID 읽기 오류나 초기화 실패가 뜨고, 펌웨어가 외부 RAM을 건드리는 순간 StoreProhibited 패닉이 뒤따르는 경우, 알려진 원인은 다섯입니다. PSRAM 다이가 없는 위조 모듈, 잘못된 PSRAM 모드(quad가 아닌 octal)로 컴파일된 펌웨어, 모듈 아래의 냉납, 초기화 구간 중의 브라운아웃, 그리고 노화된 다이입니다. 실무적인 분류는 이렇습니다. 먼저 전원을 배제하고(언제나 그렇듯), 자기 보드용 제조사 정품 이미지를 정확히 플래싱하고(이것이 올바른 PSRAM 모드를 담고 있습니다), 그래도 깨끗한 전원과 올바른 펌웨어 아래에서 오류가 계속된다면 모듈 자체가 원인입니다. 보증이나 작업대 사안이 됩니다.

오버클럭 실패: 복구와 예방

고장의 특징은 이렇습니다. 주파수나 전압을 올렸더니 크래시하게 되었다, 몇 분에서 몇 시간 뒤 해시레이트가 평평해진다, 스로틀링한다, 또는 멀티칩 보드에서 칩이 하나 사라진다. 물리 법칙은 한 가지 점에서 가차 없습니다. 클럭이 너무 높아서 생기는 불안정은 나타나기까지 시간이 걸리는 경우가 많습니다. 10분 테스트를 살아남은 설정이 보드가 완전히 열포화된 40분째에 실패할 수 있습니다. 24시간 미만의 안정성 주장이 모두 잠정적인 이유가 이것입니다.

복구(기기가 아직 부팅되는 경우):
  웹 화면 -> 주파수와 전압을 공장값으로 되돌린다 -> 저장 ->
  콜드 전원 사이클(래치된 결함이 있으면 지워진다).

복구(화면에 도달하기 전에 루프에 빠지는 경우):
  USB로 공장 이미지를 플래싱한다 —— 이것으로 출하 시 동작점이
  복원된다. 그다음 NVS를 비우기 위해 공장 초기화를 한다.

예방(방법론 전체가 다섯 줄):
  - 한 번에 25 MHz 한 단계만. 전압은 건드리지 않는다
  - 단계당 최소 30분. HW 오류율을 지켜본다
  - 오류가 2%를 넘으면 한 단계 되돌린다. 거기가 벽이다
  - 추가 발열을 감수할 각오가 있을 때에만, 거기서부터
    25 mV 단위로 전압을 올린다. 1100-1300 mV 범위를 지킨다
  - 최종 설정으로 24시간을 돌린 뒤에 안정이라고 부른다

그리고 정직한 보충을 하나. 효율을 위한 언더볼팅은 속도를 위한 오버클럭과 정확히 같은 방식으로 실패합니다. 방향만 반대일 뿐입니다. 클럭에 비해 전압이 모자라면 같은 오류와 같은 멈춤을 만들어냅니다. 실리콘 복권은 양쪽 끝에서 성립합니다.

API로 진단하기: 숙련자의 지름길

AxeOS 계열의 모든 채굴기는 80번 포트에서 REST API를 공개하고 있으며, 이것이 문제 해결의 모습을 바꿉니다. 화면이 필요 없고, 대시보드를 클릭하며 돌아다닐 필요도 없으며, 한 대에서 여러 대 운용까지 그대로 확장됩니다. 완전한 명세는 ESP-Miner 저장소의 openapi.yaml에 있습니다. 진단에 유효한 호출은 다음과 같습니다.

다섯 개의 진단용 호출

# 한 번에 전부: 해시레이트 평균, 각종 온도, 전압, 소비 전력,
# 팬 회전수, 셰어, 베스트 난이도, WiFi RSSI, 가동 시간,
# 펌웨어 버전, 여유 힙
curl http://채굴기IP/api/system/info

# ASIC 상태: 모델, 개수, 주파수, 전압
curl http://채굴기IP/api/system/asic

# 대시보드 그래프의 바탕이 되는 시계열 데이터
curl "http://채굴기IP/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# 과소평가된 것: 기기 로그를 원격으로 가져오기.
# 시리얼 케이블도 PuTTY도 필요 없다 —— 로그를 네트워크
# 너머로 가져와 아래 사전의 빨간 오류 줄로 걸러내면 된다.
curl http://채굴기IP/api/system/logs

# 어느 게 어느 것인가? 기기가 스스로를 밝히게 한다(화면 / LED)
# —— 똑같은 상자가 늘어선 선반에서는 값을 매길 수 없이 유용하다
curl -X POST http://채굴기IP/api/system/identify

이 로그 엔드포인트에는 독립된 한 문장을 할애할 가치가 있습니다. 기기가 HTTP를 반환할 정도로만 부팅된다면, 이 가이드의 시리얼 콘솔 장의 대부분은 이 호출 하나로 소파에 앉은 채 처리할 수 있습니다. 시리얼 케이블이 여전히 필요한 것은 부팅 시점의 고장과 크래시 루프뿐입니다.

/api/system/info를 정비사처럼 읽기

이 JSON의 여섯 개 필드가 질문이 던져지기 전에 대부분의 문의에 답해 줍니다.

필드(일반적인 이름)       그것이 말해주는 것
hashRate / hashrate_10m   예의 그 "주장" —— 풀과 대조할 것
temp / asicTemp           발열 장의 55-62 C 예산
vrTemp                    레귤레이터 쪽 —— BM1370/BM1373에서는
                          종종 이쪽이 진짜 제한 요인
voltage                   보드가 보는 입력 레일: 소프트웨어
                          테스터. 부하 시 4.9 V 아래로 떨어지면
                          전원이 원인. 케이스를 열지 않고
                          증명할 수 있다
power                     실제 소비 와트: "해시 중"인 기기가
                          2 W라면 USB-C 함정
sharesAccepted /          진실의 두 사람. 거부가 늘고 있다면
sharesRejected            거부 사유 표로
wifiRSSI                  -70 dBm보다 강하면 건강. 그보다
                          약하면 만료 셰어의 설명이 된다
freeHeap                  며칠에 걸쳐 조금씩 줄어든다면
                          메모리 누수 부류의 펌웨어 버그.
                          버전을 적고 트래커를 확인할 것

루프로 여러 대의 건강 상태 확인하기

한 대를 넘어서면 대시보드를 하나씩 보는 것은 그만두세요. 이 루프는 채굴기마다 한 줄짜리 건강 요약을 출력하고 죽은 것에 표시를 남깁니다.

#!/bin/bash
# fleet-check.sh - IP는 자기 기기 무리에 맞게 고쳐 쓸 것
for IP in 192.168.1.101 192.168.1.102 192.168.1.103; do
  J=$(curl -s -m 5 "http://$IP/api/system/info")
  if [ -z "$J" ]; then
    echo "$IP  도달 불가"
    continue
  fi
  echo "$J" | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('$IP  %-10s %6.1f GH/s  %4.1fC  %4.1fW  acc:%s rej:%s' % (
  d.get('hostname','?'),
  d.get('hashRate',0),
  d.get('temp',0),
  d.get('power',0),
  d.get('sharesAccepted','?'),
  d.get('sharesRejected','?')))"
done

이것을 cron으로 5분마다 돌리고 원하는 알림 채널로 흘려보내면, 새벽 2시의 장애는 아침의 놀라움이 아니라 새벽 2시 5분의 알림이 됩니다. 필드 이름은 펌웨어 버전에 따라 조금씩 다르니, 날것의 JSON을 한 번 출력해 보고 맞추세요.

API는 고치는 것도 할 수 있습니다

# 하드웨어에 손대지 않고 재시작하기
curl -X POST http://채굴기IP/api/system/restart
#   (주의: 이것은 래치된 TPS546 전원 결함을 지우지 못한다
#    —— 그쪽은 여전히 물리적으로 뽑았다 꽂아야 한다)

# 오버클럭 실험을 제정신인 값으로 되돌리기
curl -X PATCH http://채굴기IP/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# 잘못 입력한 풀 설정을 화면 없이 고치기
curl -X PATCH http://채굴기IP/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "당신의지갑주소.worker1"}'

정직한 단서 하나. 이 API에는 인증이 없습니다. 같은 LAN에 있는 누구나 당신의 채굴기를 읽고 설정을 바꿀 수 있습니다. 가정 내 네트워크라면 대개 허용 범위지만, 공유 네트워크나 손님이 들어올 수 있는 네트워크에서는 채굴기를 전용 VLAN이나 IoT 세그먼트에 넣으세요. 편리하게도 이것은 WiFi 장에서 이미 권했던 것과 같은 대처입니다.

기종별 특성: 자기 보드의 성격 알기

공통된 고장 방식과는 별개로, 보드 계열마다 디버깅을 시작하기 전에 알아둘 가치가 있는 특징적인 거동이 있습니다.

증상 마스터 표

빨간 오류 줄 사전

실제로 마주치게 될 오류 문자열을 한곳에 모아, Ctrl+F로 찾을 수 있도록 한 글자도 바꾸지 않고 적어 두었습니다. 자기 줄을 찾아 나아갈 방향을 얻으세요.

로그의 줄                          의미 -> 어디로 갈 것인가
---------------------------------------------------------------
Brownout detector was triggered    전압 강하 -> 전원
rst:0x.. (BROWNOUT_RESET)          같은 것. 리셋 배너 안에서
Power Fault Detected               TPS546 래치 -> 전원
TPS546 status / regulator fault    같은 계열 -> 전원
VCORE init failed /                펌웨어가 레귤레이터를 설정할
  device ID mismatch               수 없음: 이미지 착오 또는
                                   I2C -> ASIC + 펌웨어
i2c_master_transmit_receive err /  센서 버스 정지 -> ASIC 장의
  ESP_ERR_TIMEOUT near boot          I2C 절
Found 0 chip(s) / ASIC init fail   칩이 응답하지 않음 -> ASIC
Chip count N of M                  N+1 위치에서 체인 단선 -> ASIC
Device has overheated /            75 C에서의 차단 -> 발열
  Overheat Mode
VREG temp over limit               레귤레이터 쪽 고온 -> 발열
wifi: NO_AP_FOUND                  2.4 GHz에서의 가시성 -> 네트워크
wifi: AUTH_EXPIRE / auth fail      비밀번호 착오 -> 네트워크
wifi: beacon timeout               신호나 채널이 약함 -> 네트워크
wifi_disconnect reason: N          N을 찾아볼 것. 사유별로 대처
Stratum connection failed /        풀에 도달 불가 -> Stratum
  connect errno
authorize failed                   로그인 거부 -> Stratum,
                                   주소와 워커 확인
job not found(제출 시)             만료 셰어 -> Stratum
above target / low diff share      난이도 어긋남, 또는 HW 오류
duplicate share                    nonce 걸림 -> 전원 다시 넣고,
                                   그다음 클럭 낮추기
Guru Meditation Error: (사유)      패닉 -> 펌웨어. 괄호 안의
                                   사유 단어를 읽을 것
esp_psram: PSRAM ID read error /   PSRAM 초기화 -> 펌웨어,
  Failed to init external RAM        Nerd 계열 절
E (xx) esp_image: checksum failed  플래시 손상 -> USB 재플래싱
[www.bin / 업데이트 후 화면 백지]  복구 URL -> 펌웨어

예방 정비: 월 15분의 의식

위에 든 것들 대부분은 디버깅하는 것보다 예방하는 쪽이 값이 쌉니다.

매달
  [ ] 먼지: 핀과 팬 날개(에어 더스터. 팬은 눌러서 돌지
      않게 할 것)
  [ ] 풀 쪽에서 확인: 승인과 거부의 추이, HW 오류율이
      아직 2 미만인지
  [ ] 온도를 훑어보기: 지난달과 비교해 어긋나지 않았는가?
  [ ] 전원 커넥터를 실제로 만져보기: 미지근하면 경고,
      뜨거우면 중단

6-12개월마다
  [ ] 서멀 그리스를 다시 바르기(소모품이다)
  [ ] XT30이나 DC 잭 핀의 변색을 점검하기
  [ ] 테스터로 전원을 부하 상태에서 재확인하기

펌웨어 업데이트 때마다
  [ ] 플래싱하기 "전에" 릴리스 노트를 읽기
  [ ] 현재 버전을 적어 두기(되돌아갈 곳이 된다)
  [ ] 전원이 안정된 상태에서, 되도록 라우터 가까이에서
      플래싱하기
  [ ] 이후에 풀 설정을 재확인하기: 업데이트로 항목이
      초기화되는 경우가 있다

항상
  [ ] 예비 풀을 설정해 두기(다른 리전)
  [ ] 모든 기기에 겹치지 않는 워커 이름 쓰기
  [ ] 적어 둔 대응표: 체인 -> 지갑 주소
  [ ] 튜닝 전에 공장 출하 설정을 적어 두기

정말로 하드웨어였을 때: 무엇을 고칠 수 있는가

콜드 사이클도, 공장 초기화도, 검증된 전원에서의 올바른 이미지 재플래싱도 다 했습니다. 그런데도 고장이 남아 있습니다. 그것이 하드웨어 문제의 정의입니다. 현실적인 수리 지도는 다음과 같습니다.

• 작업대에서 수리 가능(열풍, 현미경, 안정된 손, 또는 전문가): 고장 난 TPS546이나 벅 단의 부품, 갈라진 세라믹 커패시터, ASIC이나 ESP32 모듈 아래의 냉납(리플로), 마모된 전원 커넥터, 죽은 팬. ASIC 수리를 다루는 공방이라면 어디서나 일상적인 작업입니다.
• 때로는 구할 수 있음: 5 V 레일이 완전히 단락된 보드(전원을 끈 상태에서 접지에 대해 거의 0옴) —— 더 이상 통전하지 마세요. 먼저 단락 지점을 찾아 제거해야 합니다.
• 대개 손쓸 수 없음: 방열판이 닿지 않는 상태로 몇 초를 넘겨 동작한 ASIC, 열폭주 이후의 잔해, 또는 임시방편 VRM 수리 중에 잘못된 코어 전압을 받은 칩. 단일 칩 보드에서는 칩이 가치의 대부분을 차지하므로, 어느 지점을 넘으면 교체가 수리를 이깁니다.

커뮤니티의 지원은 OSMU의 Discord와 ESP-Miner의 GitHub issue 트래커에 있습니다. 글을 올리기 전에 먼저 트래커를 검색하세요. “내 기기가 고장 났다”는 보고 중 놀랄 만한 비율이, 다음 버전에 수정이 이미 병합된 알려진 issue이기 때문입니다. 실제로 보고할 때는 완전한 보고라면 몇 시간 안에 답이 달리고, 모호한 보고는 조용히 묻힙니다. 이 템플릿을 복사하세요.

보드:       (정확한 모델 + 리비전. 예: Gamma 602)
펌웨어:     (AxeOS 버전. 대시보드 또는 /api/system/info에서)
전원:       (전압, 암페어, 제조사 —— 그리고: 부하 상태에서
             측정했는가?)
풀:         (URL + 포트 + 코인)
증상:       (한 문장으로: 무엇이 일어나는가, 언제부터인가)
계기:       (직전에 무엇을 바꿨는가: 업데이트? 운송? OC?
             방열판 재장착? 아무것도 안 했는가?)
시도한 것:  (60초 콜드 사이클? 공장 초기화? 재플래싱?
             공장 출하 주파수? 셀프 테스트 결과는?)
로그:       (시리얼 115200의 부팅 로그, 또는
             curl http://IP/api/system/logs 출력을 붙일 것
             —— 최소한 첫 E 줄과 그 앞뒤 열 줄)

이 템플릿은 관료주의가 아닙니다. 수리 공방이 가장 먼저 모으는 정보 그 자체이며, 모으는 순서까지 같습니다.

PRO: 작업대 장 —— 회로도, 측정 지점, 테스터

이 장은 회로도를 읽을 수 있고 인접한 핀을 단락시키지 않으면서 통전된 보드를 프로빙할 수 있다는 것을 전제로 합니다. 이 한 문장에서 망설였다면 여기서 멈추세요. 이 줄 위의 모든 것은 케이스를 열지 않고 해결할 수 있으며, 통전된 3 nm 보드 위에서 미끄러진 프로브는 문제 하나를 둘로 바꿉니다. 그 외의 분들께는, 여기가 오픈 하드웨어가 진짜로 보답해 주는 곳입니다.

이 보드들이 다른 어떤 채굴기와도 다른 이유

Bitaxe 하드웨어는 CERN-OHL-S 라이선스로 KiCad에서 설계되었으며, 모든 회로도, 모든 기판 레이아웃, 모든 부품표가 공개되어 있습니다. 즉 어떤 부품이 무엇인지, 어떤 레일이 어디를 지나는지 추측할 필요가 전혀 없습니다. 자기 보드의 정확한 리비전의 정확한 회로도를 열고, 그 넷을 찾아, 측정하면 됩니다. Antminer 소유자가 이 특권을 가진 적은 한 번도 없습니다. 게다가 각 하드웨어 저장소에는 거의 아무도 열어보지 않는 섹션이 있습니다. 리비전별 알려진 결함, 수정 작업, 정오 정보를 모아둔 HW issues 페이지입니다. 보드 수준의 고장을 진단하기 전에 자기 리비전에 문서화된 정오 정보가 없는지 확인하세요. “원인 불명”인 하드웨어 고장의 놀랄 만한 비율이, 그것을 고치는 수정 방법과 함께 이미 거기에 적혀 있습니다.

테스터 방법론: 세 개의 레일이 이야기 전부를 말한다

급전 경로의 고장은 순서대로 하는 세 번의 직류 측정으로 좁혀집니다. 먼저 접지를 기준으로 잡고, 순서를 지키며, 지정된 곳에서는 부하를 건 상태로 측정하세요.

레일 1 —— 입력(계열에 따라 5 V 또는 12 V)
  측정 위치: 입력 커넥터 / 입력 패드(회로도 참조)
  기대값:    5 V 계열:  해시 중에 4.9 - 5.3 V
             12 V 계열: 해시 중에 11.8 - 12.2 V
  부하 시에만 낮음 -> 전원이나 케이블(대부분의 경우)
  좋은 전원인데 0 -> 입력 보호의 소손, 또는 하류의 단락:
                     전원을 끈 상태에서 접지와의 저항을
                     측정. 거의 0옴 = 단락. 통전을 멈추고
                     그것을 찾을 것

레일 2 —— 3.3 V(ESP32의 급전)
  측정 위치: 회로도상의 3.3 V 넷(ESP32 모듈)
  기대값:    3.2 - 3.4 V로 안정
  입력이 정상인데 없음 -> 작은 쪽 3.3 V 레귤레이터나
  그 주변 수동 부품. 전원이 양품임이 증명되었는데도
  "완전히 무반응, USB 열거도 없음"인 상황을 설명한다

레일 3 —— VCORE(ASIC의 급전)
  측정 위치: TPS546 벅 단의 출력 / ASIC 코어 넷
  기대값:    대략 1.0 - 1.3 V. AxeOS에서 설정한 값과
             일치할 것
  입력도 3.3 V도 정상인데 없음 -> 벅 단: 래치된 결함
  (반드시 먼저 콜드 사이클), 또는 TPS546 / 인덕터 /
  주변 수동 부품의 고장
  존재하지만 값이 다름 -> 레귤레이터 설정이나 PMBus 통신.
  AxeOS가 설정했다고 여기는 값과 대조할 것

확인을 위한 측정
  입력 커넥터 -> 레귤레이터 입력의 도통: 끊어진 패턴이나
  갈라진 잭 납땜을 찾아낼 수 있다
  대시보드의 TPS546 다이 온도와 손을 가까이 댄 감각의 비교:
  무부하에서 다가갈 수 없을 만큼 뜨거운 레귤레이터는
  망가져 가고 있는 것이다

이 세 개의 레일이 모든 전원 고장을 갈라냅니다. 입력이 불량 = 보드보다 앞쪽. 입력은 양호하고 3.3 V가 불량 = 작은 쪽 레귤레이터. 둘 다 양호하고 VCORE가 불량 = 벅 단. 셋 다 양호 = 고장은 전원이 아니므로 ASIC 장으로 돌아갈 것. 20달러짜리 테스터와 10분이 몇 시간의 추측을 대신합니다.

수리 공방이 할 수 있는 것과 없는 것

일상적인 작업(열풍 + 현미경 + 안정된 손)
  - TPS546이나 벅 단 부품의 교체
  - 갈라진 세라믹 커패시터(육안: 본체를 가로지르는 가는
    금. 전기적: 단락 또는 개방)
  - ASIC이나 ESP32 모듈 아래의 BGA 리플로(낙하 후와
    재장착 후의 고장 부류)
  - 커넥터 교체(마모된 잭, 탄 XT30)

끈기가 있으면 가능
  - 5 V 레일의 단락 지점 추적(열화상 카메라, 또는 의심
    영역에 이소프로필 알코올을 떨어뜨려 증발을 보는 방법)
  - ESP32-S3 모듈 교체(이후 재플래싱 필요)

수지가 맞지 않음 / 손쓸 수 없음
  - 단일 칩 보드에서의 ASIC 교체: 칩이 보드 가치의
    대부분을 차지하고 공여 칩도 어차피 재생품이다.
    새 보드 쪽이 비용에서도 확실성에서도 낫다
  - 열폭주 이후, 또는 레일 전체에 역극성 입력이 가해진
    이후의 모든 상황

수리 기술자처럼 회로도 읽기

공개된 회로도를 진짜로 쓸모 있게 만드는 습관이 셋 있습니다. 첫째, 전원 트리 페이지를 찾아 무언가를 측정하기 전에 한 번 종이 위에서 입력부터 VCORE까지의 경로를 짚어 보세요. 그 시점에 당신은 그 레일을 죽일 수 있는 모든 부품을 파악하게 됩니다. 둘째, 벅 단의 부품 번호(R12, C34, U3)를 적어 두세요. 포럼 글도 정오 정보도 부품 번호로 부품을 가리키며, 레이아웃 파일을 열어 두었다면 자기 보드에서 그것들을 찾는 데는 몇 초면 됩니다. 셋째, 고장이 리비전 고유일 때는 리비전끼리 비교하세요. 예컨대 Gamma 600과 601 사이의 변경 이력은 설계자가 무엇을 고쳤는지 정확히 알려주며, 그것은 옛 쪽에서 망가지는 것과 정확히 일치하는 경우가 많습니다.

오픈소스 자료 모음

일차 자료를 전부 하나의 표에 모았습니다. 이 장을 북마크하세요. 오픈 하드웨어 가치의 절반은 원본이 어디에 있는지 아는 데 있습니다. 아래 링크는 모두 공식 출처이며 미러가 아닙니다.

핵심 정리

• 여섯 개의 영역이 거의 모든 고장을 덮는다: 전원, ASIC, 발열, 네트워크, stratum, 펌웨어. 60초 분류가 무언가를 만지기 전에 당신이 어느 영역에 있는지 알려준다.
• 전원은 첫 번째 원인이자 첫 번째 사칭자다. WiFi 크래시, 펌웨어 패닉, 걸린 칩, 죽은 보드로 위장한다. 다른 어떤 가설을 믿기 전에 먼저 부하를 걸고 입력을 측정할 것.
• 래치된 레귤레이터 결함은 모든 소프트웨어 재시작을 살아남는다. 10초에서 60초의 물리적인 뽑았다 꽂기는 미신이 아니라 진짜 진단 절차다.
• USB-C가 급전하는 것은 ESP32이지 ASIC이 아니다. USB-C만 연결된 보드는 0 GH/s의 죽은 채굴기를 완벽히 흉내 낸다.
• 115200 보드레이트 시리얼 콘솔을 익힐 것. 부팅 로그의 첫 E 줄은 어떤 포럼 스레드보다 빠르게 당신의 문제에 이름을 붙인다.
• 내장 셀프 테스트는 30초 만에 고장 난 서브시스템의 이름을 내놓고, REST API는 로그도 텔레메트리도, 때로는 수정 수단까지 네트워크 너머로 가져다준다. 시리얼 케이블을 찾으러 가기 전에 이 둘을 쓸 것.
• 12 V 전원을 5 V 보드에 절대 연결하지 말 것. 커넥터는 바꿔 꽂을 수 있지만 보드는 그렇지 않다.
• ESP32는 2.4 GHz만 말한다. 밴드 스티어링과 AP 격리가 가장 많은 설치를 망치는 두 라우터 기능이다.
• 풀 쪽의 진실이 채굴기 쪽의 낙관을 이긴다. 마지막 승인 셰어 이후 경과 시간이 유일하게 정직한 가동 검사이며 10분이 그 경계선이다.
• 지갑 주소는 채굴 중인 체인의 네이티브여야 한다. 비수탁형 풀에서 이것은 유일하게 되돌아갈 수 없는 실수다.
• 하드웨어 오류율이 정직한 성능 숫자이고, 대시보드의 해시레이트는 주장일 뿐이다. 승인 셰어를 향해 튜닝하고, 어떤 설정이든 안정이라 부르기 전에 24시간을 요구할 것.
• 뜨거운 전원 커넥터는 “나중에 디버깅”이 아니라 “지금 당장 중단”을 뜻하는 유일한 증상이다.

이 글은 ESP-Miner의 issue 트래커와 릴리스 노트, ESP-IDF의 치명적 오류 문서, 커뮤니티 수리 공방의 자료, 그리고 Bitaxe, NerdAxe, NerdQaxe 각 커뮤니티에서 반복적으로 보고되는 고장 패턴을 바탕으로 2026년 7월 20일 시점에 정리한 것입니다. 여기서 서술한 펌웨어의 거동(결함 래치, 과열 임계값, 복구 URL, 알려진 퇴행 버전 구간)은 공개 시점의 AxeOS 및 ESP-Miner 버전을 반영합니다. 자신의 버전 릴리스 노트를 확인하세요. 이 가이드는 살아 있는 참고 자료로 유지됩니다. 여기서 다루지 않은 고장 방식을 만나셨다면 문의 페이지를 통해 알려주세요. 추가하겠습니다.