게임 서버는 켜졌는데 친구가 접속하지 못할 때: 확인 순서 7단계
작성·공식 문서 확인일 2026-09-07 · SameOS operator
내 컴퓨터에서는 접속되는데 친구에게는 시간 초과가 뜨면 어디부터 봐야 할까요? 공유기 설정을 계속 바꾸기 전에 게임 프로세스 → 같은 네트워크 → 인터넷 경로 → 게임 로그인 순서로 경계를 나눠 보세요. 어느 단계까지 성공했는지 알면 바꿀 설정도 줄어듭니다. 이 글은 Linux에 직접 실행하거나 Docker bridge 네트워크로 운영하는 개인 서버를 기준으로 합니다.
1. 접속 주소와 실패 시점을 먼저 적기
게임 이름·에디션, 서버와 클라이언트 버전, 입력한 주소와 포트, 테스트한 네트워크, 오류 문구를 적습니다. 같은 Minecraft라도 Java와 Bedrock의 접속 방식을 섞으면 포트 규칙을 고쳐도 해결되지 않습니다. 접속 시각을 분 단위로 남기면 서버 로그와 맞출 수 있습니다.
주소 자체를 못 찾는 오류, 응답을 기다리다 끝나는 시간 초과, 서버가 보낸 버전·화이트리스트 거절은 서로 다른 단계입니다. 서버 이름이 목록에 뜨는 것만으로 월드 접속까지 성공했다고 판단하지 마세요.
2. 프로세스 실행과 월드 준비를 구분하기
서비스가 active이거나 컨테이너가 Up이어도 월드 로딩이 끝나지 않았을 수 있습니다. 최근 로그에서 준비 완료와 반복 오류를 확인하고, 재시작 횟수가 계속 늘면 네트워크보다 기동 실패부터 해결합니다. 아래 minecraft와 mc-server는 예시 이름입니다.
systemd 설치면 앞의 두 명령을, Docker 설치면 뒤의 두 명령을 사용합니다. 공개 게시판에 로그를 올릴 때는 접속 주소·플레이어 식별자·인증 정보를 가립니다.
systemctl status minecraft --no-pager -l
journalctl -u minecraft -b -n 100 --no-pager
docker ps -a --filter name=mc-server
docker logs --since 10m --tail 100 mc-server3. TCP·UDP와 바인딩 주소 확인
Minecraft Java의 일반 게임 접속은 기본 TCP 25565를 사용합니다. Palworld의 기본 게임 포트 예시는 UDP 8211입니다. 실제 실행 인수에서 포트를 바꿨다면 그 값을 기준으로 확인하세요. 숫자만 같고 프로토콜이 다르면 다른 통로입니다.
호스트에 직접 실행했다면 아래 소켓 목록에서 포트와 프로세스를 확인합니다. 127.0.0.1에만 묶여 있으면 다른 기기에서 직접 접근할 수 없습니다. 0.0.0.0은 IPv4 인터페이스에서 받을 준비가 됐다는 뜻이며 공유기나 방화벽까지 통과했다는 뜻은 아닙니다. IPv6 표시는 IPv4 접근 가능 여부와 따로 확인합니다.
sudo ss -lntp
sudo ss -lnup4. Docker는 컨테이너 안 포트와 공개 포트를 따로 보기
Docker bridge에서는 게임 내부 포트와 호스트에 공개한 포트가 일치하는지 봅니다. 25566:25565/tcp로 설정했다면 친구에게 줄 호스트 포트는 25566입니다. 호스트의 ss 목록만으로 Docker NAT 공개 여부를 전부 판단할 수 없으므로 docker port도 확인합니다.
Palworld에 8211:8211만 쓰면 기본 TCP로 해석될 수 있으므로 UDP 공개인지 확인합니다. 127.0.0.1:25565:25565처럼 localhost로만 공개한 규칙도 외부 접속에는 맞지 않습니다. 포트 공개는 접근 범위를 넓히므로 게임 포트와 관리자용 RCON·REST 포트를 구분해서 검토하세요.
docker port mc-server
docker inspect --format '{{json .HostConfig.PortBindings}}' mc-server5. 집 안 접속과 집 밖 접속을 따로 시험
먼저 같은 공유기에 연결된 다른 기기에서 서버의 내부 주소로 실제 게임 접속을 시도합니다. 이 단계가 실패하면 공유기의 외부 포트포워딩보다 호스트 방화벽, Docker 공개, Wi-Fi 게스트망 격리를 확인합니다.
내부 접속이 성공하면 외부 네트워크의 친구에게 공인 주소로 접속을 요청합니다. 집 안에서 공인 주소로 접속하는 시험은 공유기의 NAT loopback 지원에 따라 실패할 수 있습니다. 외부만 실패하면 포트포워딩 대상 내부 IP와 프로토콜, 클라우드 보안 규칙, 이중 공유기 구성을 차례로 봅니다.
공유기 WAN 주소가 사설 주소이거나 통신사 공유 주소라면 내 공유기만 설정해도 외부에서 들어오지 못할 수 있습니다. 상위 공유기를 직접 관리하는지, 통신사가 인바운드 가능한 공인 주소를 제공하는지 확인합니다. DMZ나 방화벽 전체 해제로 원인을 가리는 방식은 피합니다.
6. 포트 확인 사이트의 성공·실패를 과신하지 않기
TCP 확인 도구는 TCP 연결 여부를 확인할 뿐 UDP 게임의 접속 성공을 증명하지 못합니다. UDP는 응답이 없다는 것만으로 열림과 차단을 구분하기 어려운 경우가 있어 실제 게임 클라이언트와 서버 로그를 함께 봐야 합니다.
친구의 접속 시각에 로그에 아무 흔적이 없으면 네트워크 경로를 의심할 수 있지만, 게임이 모든 실패 요청을 기록한다는 보장은 없습니다. 반대로 버전 불일치나 허용 목록 오류가 찍히면 적어도 게임에 요청이 도달한 근거가 있으므로 그 메시지부터 해결합니다.
7. 연결 이후 거절과 완료 기준
네트워크가 통하면 서버·클라이언트 빌드, 필수 모드와 로더, 암호·허용 목록을 확인합니다. 설정 하나를 바꾼 뒤 같은 주소·같은 클라이언트로 다시 시험해야 어느 변경이 효과가 있었는지 알 수 있습니다. 친구 한 명만 실패한다면 다른 친구의 성공 시각과 비교해서 해당 클라이언트나 네트워크 차이를 좁힙니다.
완료 기준은 외부 기기에서 올바른 월드에 접속하고, 이동·상호작용 후 재접속해도 유지되는 것입니다. 접속 주소와 포트, 바뀐 공유기 규칙을 기록하고 서버 내부 IP는 DHCP 예약 등으로 유지합니다. 다음 재부팅 때 대상 주소가 바뀌면 같은 문제가 반복됩니다.
검증 범위와 공식 참고자료
공식 문서와 명령 옵션을 확인해 작성한 Linux 운영 가이드입니다. 이 글의 경로·서비스명·주소와 진단 상황은 설명용이며 실제 SameOS 게임 서버 장애 기록이나 성능 측정값이 아닙니다. 운영 서버에서 장애를 유발하거나 저장 데이터를 변경하는 실험은 하지 않았습니다. 게임 빌드와 설치 방식에 따라 설정·저장 위치가 다르므로 실제 환경을 확인한 뒤 적용하세요.