게임 렉 백서 › 증상별로 찾기
접속 불가·무한 로딩: 원인 45가지와 담당
다른 말: 로그인 안 됨, 로딩이 끝나지 않음
그림이 있는 원본 증상 사전으로 열기 →
게임 안으로 들어가지 못하거나, 로딩·입장 화면에서 멈춰 있습니다.
“서버에 연결할 수 없습니다” 반복, 캐릭터 선택 후 로딩바가 끝나지 않음.
새 연결을 받아 주는 곳(서버의 접속 대기열, 방화벽, 로그인 서버, DB)이 가득 찼습니다. 점검 직후에 특히 많습니다.
이 증상을 만드는 원인
L2 클라이언트 OS·기기
- 보안 프로그램의 패킷 검사: 백신·방화벽이 모든 패킷을 검사하면 지연이 늘고 과하면 게임을 공격으로 오인해 막습니다. (외부·외부)
L3 집 네트워크
- 공유기 성능 부족·과열: 값싼 공유기에 기기 수십 대, 연결 수천 개가 몰리면 공유기 자체가 처리를 못 합니다. (외부·외부)
- 공용 와이파이·회사망 제한: 카페 와이파이 로그인 페이지나 회사 방화벽이 게임 연결을 막습니다. (외부·외부)
L4 인터넷 회선
- 국가·통신사 단위 UDP 제한·패킷 검사: 일부 망은 특정 UDP 주소·포트를 막거나 UDP 속도를 제한하고 패킷 검사 장비가 알아보지 못하는 프로토콜을 걸러 냅니다. UDP로 통신하는 게임은 그 망에서 접속이 안 되거나 자주 끊깁니다. (외부·외부)
- DNS 장애·지연: 서버 이름을 주소로 바꿔 주는 DNS가 느리거나 실패하면 로그인·패치 서버를 찾지 못합니다. (외부·외부)
- DDoS로 인한 공유 회선 포화: 게임사나 같은 망의 다른 곳을 향한 대량 공격이 공유 회선을 가득 채웁니다. (인프라팀·네트워크 인프라)
- 통신사 공유 IP (CGNAT): 모바일망과 일부 통신사는 여러 가입자가 IP 하나를 나눠 쓰며 유휴 연결의 매핑을 짧은 시간 안에 지웁니다. (게임개발팀·클라이언트 개발)
- VPN·게임 가속기 경유: VPN이나 게임 가속기를 켜면 패킷이 그 회사의 중계 서버를 거쳐 갑니다. 중계 서버가 멀거나 붐비면 오히려 느려집니다. (외부·외부)
L5 데이터센터 네트워크 장비
- 방화벽 세션 테이블 포화: 방화벽은 통과시킨 모든 연결을 세션 테이블에 기록해 추적합니다. 테이블이 다 차면 새 연결을 받을 수 없습니다. (인프라팀·네트워크 인프라)
- DDoS 방어 경유·오탐: 공격을 막으려고 트래픽을 스크러빙 센터로 돌리면 경로가 길어지고 정상 사용자를 공격으로 오인해 막기도 합니다. (인프라팀·네트워크 인프라)
- 클라우드 NAT 게이트웨이 연결·포트 한도: 사설 서브넷의 서버가 외부(플랫폼 인증·결제·외부 API)로 나가는 연결은 NAT 게이트웨이가 주소와 포트를 바꿔 내보냅니다. 같은 목적지로 가는 동시 연결이 게이트웨이의 포트 한도를 넘으면 새 연결이 실패합니다. (인프라팀·네트워크 인프라)
- 로드밸런서 쏠림·헬스체크 오판: 로드밸런서가 한 서버에만 연결을 몰아주거나, 이미 죽은 서버로 계속 사람을 보냅니다. (인프라팀·네트워크 인프라)
- MTU 불일치 (큰 패킷만 사라짐): 중간 구간의 MTU(한 번에 보낼 수 있는 크기)가 줄었는데 크기 초과 알림이 막히면, 큰 패킷만 계속 사라집니다. (인프라팀·네트워크 인프라)
L7 서버 OS (커널)
- 접속 대기열(backlog) 넘침: 점검 직후 수만 명이 동시에 접속하면, 커널의 접속 대기열(backlog)이 넘쳐 접속 시도가 버려집니다. (게임개발팀·서버 개발)
- 파일 디스크립터 한도: 연결 하나마다 파일 디스크립터(fd, OS가 열린 파일·소켓에 붙이는 번호)가 필요한데, 한 프로세스가 열 수 있는 fd 수가 제한되어 있습니다. (인프라팀·서버 인프라)
- 서버 conntrack 테이블 포화: 리눅스 방화벽이 모든 연결을 기록하는 연결 추적(conntrack) 테이블이 한도에 닿으면 새 패킷을 버립니다. (인프라팀·서버 인프라)
- 서버 간 연결의 임시 포트 고갈: 게임 서버가 DB나 다른 서버에 연결을 짧게 자주 맺고 끊으면, 끊긴 연결이 한동안 포트를 점유해 새 연결을 못 엽니다. (게임개발팀·서버 개발)
L8 소켓과 프로토콜
- keepalive 기본값 2시간: 상대가 종료 신호 없이 사라지면 TCP는 한참 뒤에야 감지합니다. keepalive(유휴 연결이 살아 있는지 확인하는 TCP 기능)는 기본으로 꺼져 있고, 켜도 2시간 동안 유휴 상태여야 확인을 시작합니다. (게임개발팀·서버 개발)
- SO_REUSEPORT 분배 쏠림: 같은 포트를 여러 프로세스가 나눠 받으면, 커널은 접속마다 주소 해시로 담당 프로세스를 정해 두고 바꾸지 않습니다. 담당 프로세스 하나가 멈추면 거기에 배정된 사람만 기다립니다. (게임개발팀·서버 개발)
L9 서버 게임 프로세스
- 스레드 풀 고갈: 작업을 처리할 워커 스레드가 모두 느린 작업에 묶이면 새 요청은 무작정 기다립니다. (게임개발팀·서버 개발)
L11 디스크
- 코어 덤프 기록: 서버가 죽을 때 수 GB 메모리를 디스크에 기록하느라 재시작이 몇 분씩 늦어지기도 합니다. (인프라팀·서버 인프라)
L12 데이터베이스
- 인덱스 없는 쿼리: 인덱스 없이 조건에 맞는 행을 찾으려면 테이블 전체를 읽어야 합니다(풀 스캔). (게임개발팀·서버 개발)
- 커넥션 풀 고갈: DB와 맺어 둔 연결 수가 정해져 있어서 느린 쿼리가 연결을 점유하면 나머지는 대기합니다. (게임개발팀·서버 개발)
- 콜드 캐시 (재시작 직후): DB를 재시작하면 메모리 캐시가 비어 있어서 한동안 조회하는 데이터를 모두 디스크에서 읽습니다. (인프라팀·DB 인프라)
- 로그인 폭주와 N+1 쿼리: 캐릭터 하나를 불러올 때 수십 번 따로 조회하면, 수만 명 동시 로그인이 쿼리 수백만 개가 됩니다. (게임개발팀·서버 개발)
- DB 장애 전환: 주 DB가 죽어 예비 DB로 전환되는 동안 쓰기가 안 되고 복제되지 못한 마지막 데이터는 사라질 수 있습니다. (인프라팀·DB 인프라)
- 캐시 스탬피드: 인기 데이터의 캐시가 동시에 만료되면 수천 개 요청이 한꺼번에 DB로 몰립니다. (게임개발팀·서버 개발)
- Redis 느린 명령: Redis는 명령을 한 번에 하나씩 처리해서 느린 명령 하나가 그 뒤의 모든 요청을 막습니다. (게임개발팀·서버 개발)
- 실행 계획 변경으로 인한 쿼리 지연: 코드는 그대로인데 DB가 같은 쿼리를 처리하는 방법(실행 계획)을 바꾸면, 어제 2ms였던 쿼리가 오늘 수백 ms가 됩니다. (인프라팀·DB 인프라)
- 운영 중 스키마 변경(DDL) 잠금: 서비스 중에 테이블에 컬럼이나 인덱스를 추가하면, 잠깐 필요한 잠금 하나 때문에 그 테이블을 쓰는 모든 요청이 대기할 수 있습니다. (인프라팀·DB 인프라)
L13 서버 구성과 운영
- 존 이동 (서버 간 이관): 다른 지역·던전에 들어갈 때 캐릭터 정보를 다른 서버로 넘기는 과정에서 지연과 실패가 생깁니다. (게임개발팀·서버 개발)
- 연쇄 장애: 한 서비스가 느려지면 그걸 부르는 서버들이 응답을 기다리며 묶이고 상관없는 기능까지 멈춥니다. (게임개발팀·서버 개발)
- 부가 서버 장애: 채팅·파티·경매장처럼 게임 서버와 따로 도는 서버에 장애가 나면 그 기능만 동작하지 않습니다. (게임개발팀·서버 개발)
- 배포·재시작: 업데이트하려고 서버를 재시작할 때 연결을 옮기지 않으면 그 서버에 있던 사람들의 접속이 끊기고, 종료 직전 저장과 재접속이 한꺼번에 몰립니다. (게임개발팀·서버 개발)
- 오토스케일링 지연: 사람이 몰리면 서버를 자동으로 늘리지만 준비에 몇 분이 걸리고 그동안 기존 서버가 과부하입니다. (인프라팀·서버 인프라)
- 외부 서비스 의존: 플랫폼 로그인, 결제, 본인 인증 같은 외부 서비스가 느리거나 멈추면 그 단계에서 막힙니다. (외부·외부)
- TLS 인증서 만료·설정 오류: 로그인·API·패치 서버의 인증서가 만료되거나 중간 인증서가 빠지면, 그 순간부터 새로 연결하는 클라이언트의 TLS 연결이 실패합니다. (인프라팀·네트워크 인프라)
- 로그인 대기열 상한·재접속 유예 부족: 출시·점검 직후 접속이 몰리면 로그인 대기열이 상한에 닿아 새 대기를 거절하고, 기다리던 유저는 잠깐 끊긴 사이 자리를 잃어 맨 뒤로 돌아갑니다. (게임개발팀·서버 개발)
동기화 설계
일부에게만 생기는 문제
- 특정 캐릭터의 데이터가 비대함: 아이템·우편이 수천 개 쌓였거나 친구·차단 목록, 버프가 유난히 많은 캐릭터는 접속하고 저장하고 주변에 알릴 양이 남보다 몇 배 큽니다. 회선과 상관없이 그 캐릭터로만 느립니다. (게임개발팀·서버 개발)
- 고정 UDP 포트 충돌: 클라이언트가 정해진 로컬 포트를 쓰도록 만들어져 있으면, 같은 PC의 두 번째 클라이언트는 포트를 못 쓰거나 첫 번째와 패킷을 나눠 받습니다. (게임개발팀·클라이언트 개발)
- 멀티 클라이언트 제한: 보안 모듈이나 서버 정책이 한 PC의 여러 클라이언트를 제한하면, 두 번째 클라이언트는 실행·접속이 막히거나 먼저 켠 쪽의 접속이 끊깁니다. 일부 게임은 추가 클라이언트의 기능만 막습니다. (게임개발팀·클라이언트 개발)
TCP 재전송의 근본 원인
- 방화벽·연결 추적의 폐기: 방화벽이나 리눅스 연결 추적(conntrack, 지나가는 연결을 테이블에 기록하는 기능)은 테이블이 가득 차거나, 연결 상태가 맞지 않는다고 판단하면 패킷을 버립니다. (인프라팀·네트워크 인프라)
- MTU 블랙홀 (큰 패킷만 반복 손실): 중간 구간이 받을 수 있는 크기가 작아졌는데 “너무 크다”는 알림(ICMP)이 막히면, 큰 패킷은 몇 번을 다시 보내도 계속 사라집니다. (인프라팀·네트워크 인프라)
- 접속 요청(SYN) 재전송: 접속 요청이 접속 대기열(backlog) 넘침이나 방화벽 차단으로 사라지면, 클라이언트 OS가 1초 뒤부터 간격을 늘려 가며 다시 보냅니다. (게임개발팀·서버 개발)
그림이 있는 원본 증상 사전 보기