피어 수가 적다는 숫자만으로 노드가 고장났다고 볼 수 없습니다. 아웃바운드 연결은 다른 피어에게 먼저 접속해 블록과 거래를 받는 경로이고, 인바운드 연결은 외부 피어가 내 노드에 들어오는 경로입니다. 인바운드가 0이어도 아웃바운드 피어가 정상이고 최신 블록을 받고 있다면 동기화는 가능합니다. 포트 전달과 방화벽은 주로 외부에서 내 노드에 접근할 수 있는지에 영향을 주므로 연결 방향, 최근 블록 수신 시각, 체인 진행을 함께 봐야 합니다.
연결 수를 보기 전에 방향부터 나눕니다
Bitcoin Core의 getnetworkinfo는 전체 connections뿐 아니라 connections_in과 connections_out을 따로 제공합니다. 아웃바운드는 내 노드가 알려진 주소를 찾아 밖으로 연결한 피어이고, 인바운드는 외부 노드가 공개된 내 주소와 포트로 들어온 피어입니다. 두 방향은 네트워크 기여와 장애 원인이 다르므로 합계 하나만 보면 진단이 흐려집니다.
가정에서 공유기 NAT 뒤에 노드를 두면 별도 포트 전달 없이 인바운드가 0인 경우가 흔합니다. 그래도 아웃바운드 피어를 통해 헤더와 블록을 받아 검증할 수 있습니다. 반대로 인바운드가 여럿 보여도 모두 오래되거나 유용한 블록을 보내지 않는다면 최신 동기화 여부는 별도로 확인해야 합니다.
좋은 피어 상태는 숫자가 많다는 뜻보다 서로 다른 경로에서 최신 체인 자료를 계속 받는다는 뜻에 가깝습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 연결 수를 보기 전에 방향부터 나눕니다
Bitcoin Core의 getnetworkinfo는 전체 connections뿐 아니라 connections_in과 connections_out을 따로 제공합니다.
- 피어 수와 동기화 상태를 같은 화면에서 대조합니다
getnetworkinfo의 networkactive가 false라면 P2P 네트워크가 비활성화된 상태이므로 포트보다 먼저 설정을 확인해야 합니다.
- 포트 전달은 동기화의 필수 조건이 아닙니다
기본 비트코인 메인넷 P2P 포트가 외부에서 도달 가능하면 다른 노드가 내 노드에 인바운드 연결을 만들 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
피어 수와 동기화 상태를 같은 화면에서 대조합니다
getnetworkinfo의 networkactive가 false라면 P2P 네트워크가 비활성화된 상태이므로 포트보다 먼저 설정을 확인해야 합니다. connections_out이 0이고 headers와 blocks도 멈췄다면 DNS 시드 접근, 프록시, VPN, 로컬 방화벽의 아웃바운드 정책을 살핍니다. 연결은 있지만 blocks가 고정되면 getpeerinfo에서 last_block, synced_headers, synced_blocks 같은 피어별 상태를 확인할 수 있습니다.
Bitcoin Core 0.21 릴리스부터 getpeerinfo에는 connection_type과 network, 마지막 블록·거래 수신 시각 같은 진단 정보가 추가됐습니다. 피어가 IPv4, IPv6, onion 중 어느 경로인지, 수동 addnode인지 자동 아웃바운드인지 구분하면 한 네트워크 경로에만 의존하는 문제도 찾을 수 있습니다. 버전별 필드 차이가 있으므로 현재 실행 버전의 RPC 도움말을 기준으로 해석하세요.
| 관찰 | 해석 가능성 | 우선 확인 |
|---|---|---|
| 인바운드 0, 아웃바운드 존재 | NAT 뒤 일반 연결 | blocks와 last_block 진행 |
| 전체 연결 0 | P2P 비활성·차단 가능 | networkactive·프록시·방화벽 |
| 연결 존재, 체인 정지 | 피어 품질 또는 검증 문제 | getpeerinfo·debug.log |
| 인바운드만 갑자기 감소 | 포트·공인 주소 변화 | NAT·포트 전달·리스닝 |
| 한 네트워크 유형만 연결 | 경로 제한 설정 가능 | networks의 reachable·limited |
포트 전달은 동기화의 필수 조건이 아닙니다
기본 비트코인 메인넷 P2P 포트가 외부에서 도달 가능하면 다른 노드가 내 노드에 인바운드 연결을 만들 수 있습니다. 그러나 공유기에서 포트를 열었다는 사실만으로 인터넷에서 도달 가능한 것은 아닙니다. 이중 NAT, 통신사 CGNAT, 운영체제 방화벽, 노드의 listen 설정, 잘못된 내부 IP 전달이 차례로 경로를 막을 수 있습니다.
공개 포트는 공격 표면과 운영 책임도 늘립니다. RPC 포트는 P2P 포트와 역할이 완전히 다르며 인터넷에 공개해서는 안 됩니다. 포트 전달 규칙을 만들 때 대상 포트와 내부 호스트를 정확히 확인하고, 외부 검사 결과와 노드 로그의 실제 인바운드 수신을 함께 봅니다. 관리 인터페이스나 RPC 인증을 P2P 공개와 섞지 마세요.
- getnetworkinfo에서 networkactive와 방향별 연결 수를 기록합니다.
- getpeerinfo에서 connection_type과 최근 블록 수신을 확인합니다.
- headers·blocks가 시간에 따라 증가하는지 대조합니다.
- 인바운드가 필요할 때만 NAT와 방화벽 규칙을 점검합니다.
- RPC 포트를 P2P 포트 전달 규칙에 포함하지 않습니다.
연결이 적어도 무작정 addnode를 늘리지 않습니다
수동 피어를 많이 추가하면 피어 발견 문제를 가릴 수 있고 특정 운영자에게 연결이 편중될 수 있습니다. 먼저 자동 주소 발견과 DNS, 프록시 설정이 정상인지 확인하세요. 임시 진단을 위해 신뢰할 수 있는 피어 하나를 추가했더라도 원인이 해결된 뒤 수동 의존을 유지할 이유가 있는지 검토해야 합니다.
피어가 자주 바뀌는 것은 P2P 네트워크에서 어느 정도 정상입니다. 단일 순간의 연결 수보다 하루 동안 최신 블록을 놓치지 않는지, 동일 네트워크·동일 주소 대역에 연결이 몰리지 않는지, 반복적인 disconnect 이유가 무엇인지가 더 중요합니다. 로그를 남길 때 피어 주소에 개인 네트워크 정보가 포함될 수 있으므로 공개 공유 전 마스킹하세요.
인바운드 운영은 네트워크 기여 목적을 분명히 합니다
인바운드를 허용하면 다른 노드가 블록과 거래를 받는 데 기여할 수 있지만, 프루닝 설정과 서비스 플래그에 따라 제공 가능한 과거 데이터 범위가 달라집니다. 인바운드 수가 많다는 이유만으로 모든 과거 블록을 제공하는 아카이브 노드라고 설명하면 안 됩니다. localservicesnames와 프루닝 상태를 함께 확인해야 합니다.
점검 결과는 ‘연결 가능’, ‘최신 동기화’, ‘인바운드 공개’, ‘과거 블록 제공’을 각각 분리해 기록하세요. 한 항목의 성공이 다른 항목을 자동 증명하지 않습니다. 노드 운영 목적이 개인 검증이라면 안정적인 아웃바운드와 체인 진행을 먼저 확보하고, 네트워크 기여까지 원할 때 인바운드 공개를 별도 단계로 진행하는 편이 안전합니다.
문제가 반복되면 시각별 최소 증거를 남깁니다
연결 장애 시각, connections_in·out, headers·blocks, networkactive, 프록시 사용 여부를 한 줄로 묶어 기록합니다. 이어 getpeerinfo의 마지막 블록 수신 시각과 debug.log 오류를 붙이면 포트 문제, 피어 발견 문제, 검증 정지를 구분하기 쉬워집니다. 단순히 ‘피어 2개’라는 숫자만 저장하면 어느 방향인지조차 알 수 없습니다.
설정 변경 후에는 노드를 재시작했다는 사실만으로 해결 완료라 하지 말고 같은 지표가 회복됐는지 확인하세요. 아웃바운드 연결 생성, 새 헤더 수신, blocks 증가가 순서대로 관찰되면 동기화 경로가 복구됐다는 근거가 됩니다. 인바운드는 외부에서 실제 접속된 피어가 나타나는지 별도로 검증해야 합니다.
자주 묻는 질문
인바운드 피어가 0이면 포트 8333을 꼭 열어야 하나요?
개인 노드의 동기화만 목적이라면 아웃바운드 연결로 진행할 수 있습니다. 다른 노드의 인바운드를 받으려는 목적이 있을 때 NAT와 방화벽을 점검하세요.
피어 수가 많으면 더 안전한가요?
숫자만으로 보장되지 않습니다. 연결 방향, 네트워크 다양성, 최신 블록 수신, 체인 검증 진행을 함께 봐야 합니다.
RPC 포트도 함께 열어야 하나요?
아닙니다. RPC는 관리 인터페이스이며 P2P 포트와 다릅니다. 인터넷 공개는 자격증명과 자금에 큰 위험을 만들 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
