최근 현장에서 공유기 LAN IP를 변경한 뒤, PC는 새 IP 대역을 정상적으로 받았는데도 공유기 관리 페이지 접속과 프로그램의 WebSocket 연결이 실패하는 상황이 있었습니다.
예를 들어 공유기 LAN IP를 192.168.10.1에서 192.168.123.1로 변경한 뒤, PC의 IP는 새 대역으로 정상 변경되었고 ping도 일부 정상으로 보였지만, 브라우저에서 공유기 설정 페이지가 열리지 않거나 프로그램에서 WebSocket 연결이 되지 않았습니다.
결론부터 말하면, 단순히 PC가 새 IP를 받았다고 해서 네트워크 서비스 상태가 완전히 갱신된 것은 아닐 수 있습니다.
1. 발생 상황
공유기 LAN IP 변경 후 다음과 같은 증상이 발생했습니다.
-
PC는 새 IP 대역을 정상적으로 할당받음
-
ifconfig또는ip addr상으로 IP는 정상으로 보임 -
공유기 IP로
ping이 되는 경우도 있음 -
하지만 브라우저에서 공유기 관리 페이지 접속 실패
-
프로그램에서 WebSocket 연결 실패
-
시간이 지나도 불안정하거나 접속되지 않음
-
공유기, PC, 연결 장비를 모두 재부팅하니 정상 동작
2. 가능한 원인
1) 공유기 내부 서비스가 완전히 재시작되지 않았을 가능성
공유기의 LAN IP를 변경하면 단순히 IP 주소만 바뀌는 것이 아니라, 내부적으로 여러 서비스가 다시 설정되어야 합니다.
예를 들면 다음과 같습니다.
-
DHCP 서버
-
NAT / 라우팅 테이블
-
DNS 프록시
-
관리자 웹 서버
-
방화벽 규칙
-
내부 세션 테이블
공유기 설정 화면에서는 변경이 완료된 것처럼 보여도, 내부 서비스 중 일부가 아직 이전 IP 기준으로 동작하거나 완전히 재시작되지 않은 상태일 수 있습니다.
이 경우 PC는 새 IP를 받았지만, 공유기 관리 페이지나 특정 포트 서비스는 정상 응답하지 않을 수 있습니다.
2) PC의 ARP 캐시가 이전 공유기 정보를 기억하고 있었을 가능성
PC는 IP 주소와 MAC 주소의 매핑 정보를 ARP 캐시에 저장합니다.
예를 들어 이전에 공유기가 192.168.10.1이었고, 이후 192.168.123.1로 변경되었더라도 PC 또는 주변 장비가 기존 네트워크 정보를 일부 기억하고 있으면 통신이 꼬일 수 있습니다.
이 경우 ping은 되는 것처럼 보여도, 브라우저나 WebSocket 같은 TCP 기반 연결은 실패할 수 있습니다.
확인 명령 예시는 다음과 같습니다.
ip neigh
ARP 캐시 초기화 예시는 다음과 같습니다.
sudo ip neigh flush all
3) 브라우저 세션 또는 캐시 문제
공유기 관리 페이지는 브라우저 세션, 쿠키, 리다이렉트 정보, HTTPS 예외 정보 등에 영향을 받을 수 있습니다.
LAN IP 변경 후에도 브라우저가 이전 주소나 이전 세션 정보를 참조하면 다음과 같은 문제가 생길 수 있습니다.
-
관리 페이지가 열리지 않음
-
로그인 화면이 뜨지 않음
-
이전 IP로 리다이렉트됨
-
페이지가 무한 로딩됨
-
HTTPS 인증서 오류 또는 보안 예외 문제 발생
따라서 공유기 설정 페이지 접속이 안 될 때는 일반 탭이 아니라 시크릿 창이나 다른 브라우저로 접속해보는 것이 좋습니다.
4) 프로그램의 WebSocket 연결 주소가 이전 IP를 사용했을 가능성
WebSocket 프로그램은 브라우저보다 더 민감하게 IP, 포트, 프로토콜 상태의 영향을 받습니다.
예를 들어 프로그램 내부에서 다음과 같은 주소를 사용하고 있었다면,
ws://192.168.10.5:포트
wss://192.168.10.5:포트
공유기 대역 변경 후에는 해당 IP가 더 이상 유효하지 않을 수 있습니다.
PC나 장비가 새 IP를 받았더라도 프로그램 설정 파일, 실행 인자, 브라우저 URL, WebSocket 서버 주소가 이전 IP를 바라보고 있으면 연결은 실패합니다.
즉, ping이 된다고 해서 WebSocket이 된다는 뜻은 아닙니다.
WebSocket은 다음 조건이 모두 맞아야 합니다.
-
서버 장비 IP가 맞아야 함
-
포트가 열려 있어야 함
-
서버 프로세스가 실행 중이어야 함
-
ws://또는wss://프로토콜이 맞아야 함 -
방화벽에서 차단되지 않아야 함
-
클라이언트가 새 주소를 사용해야 함
5) DHCP 갱신은 되었지만, 일부 장비는 이전 네트워크 상태를 유지했을 가능성
PC는 새 IP를 받았더라도, 다른 장비나 프로그램은 이전 네트워크 상태를 유지할 수 있습니다.
예를 들어 다음과 같은 경우가 있습니다.
-
공유기는 새 대역으로 변경됨
-
PC는 새 IP를 받음
-
로봇 또는 서버 장비는 이전 IP를 유지함
-
WebSocket 서버는 이전 IP 기준으로 실행 중
-
클라이언트 프로그램은 이전 IP로 접속 시도
이 경우 같은 Wi-Fi에 연결되어 있어 보여도 실제로는 서로 다른 네트워크 상태를 바라보는 문제가 생깁니다.
3. 왜 재부팅하면 해결됐는가?
공유기와 PC, 장비를 모두 재부팅하면 다음 상태들이 강제로 초기화됩니다.
-
공유기 내부 네트워크 서비스
-
DHCP 할당 상태
-
ARP 캐시
-
라우팅 테이블
-
브라우저/프로그램의 기존 연결 세션
-
WebSocket 서버/클라이언트 연결 상태
-
장비의 네트워크 인터페이스 상태
즉, 재부팅은 단순한 해결책이 아니라 네트워크 변경 후 남아 있던 이전 상태를 모두 정리하는 과정입니다.
이번 문제는 IP 설정 자체가 틀렸다기보다는, LAN IP 변경 이후 공유기와 각 장비의 네트워크 상태가 완전히 동기화되지 않아 발생한 문제로 보는 것이 가장 타당합니다.
4. 점검 순서
비슷한 문제가 발생하면 아래 순서로 확인하면 좋습니다.
1) 현재 PC IP 확인
ip addr
또는
ifconfig
확인할 것:
-
PC가 새 공유기 대역의 IP를 받았는지
-
예: 공유기
192.168.123.1이면 PC는192.168.123.x대역이어야 함
2) 기본 게이트웨이 확인
ip route
확인할 것:
default via 192.168.123.1
기본 게이트웨이가 새 공유기 IP로 잡혀 있어야 합니다.
3) 공유기 ping 확인
ping 192.168.123.1
단, ping 성공은 최소한의 연결 확인일 뿐입니다.
ping이 된다고 해서 웹 관리 페이지나 WebSocket이 반드시 정상이라는 의미는 아닙니다.
4) 공유기 관리 페이지 확인
브라우저에서 접속합니다.
http://192.168.123.1
접속이 안 되면 다음을 시도합니다.
-
시크릿 창으로 접속
-
다른 브라우저로 접속
-
http://를 명시해서 접속 -
브라우저 캐시 삭제
-
PC 네트워크 재연결
-
공유기 재부팅
5) ARP 캐시 초기화
sudo ip neigh flush all
이후 다시 확인합니다.
ip neigh
6) WebSocket 서버 IP와 포트 확인
서버 장비에서 IP를 확인합니다.
ip addr
서버 포트가 열려 있는지 확인합니다.
ss -lntp
또는
netstat -lntp
확인할 것:
-
WebSocket 서버가 실행 중인지
-
포트가 열려 있는지
-
서버 IP가 새 네트워크 대역인지
-
클라이언트 URL이 새 IP를 바라보고 있는지
5. 예방 방법
공유기 LAN IP를 변경할 때는 아래 순서로 진행하는 것이 좋습니다.
-
공유기 LAN IP 변경
-
공유기 저장 및 재부팅
-
PC Wi-Fi 연결 해제 후 재연결
-
PC IP / 게이트웨이 확인
-
공유기 관리 페이지 접속 확인
-
로봇, 서버, 클라이언트 장비 재부팅 또는 네트워크 재연결
-
WebSocket 서버 IP와 포트 확인
-
프로그램 설정의 IP 주소 갱신
-
최종 연결 테스트
6. 정리
이번 문제의 핵심은 "IP를 정상적으로 받았는가?"가 아니라 "네트워크 변경 후 모든 장비와 서비스가 새 상태로 완전히 갱신되었는가?"입니다.
공유기 LAN IP를 변경하면 PC의 IP만 바뀌는 것이 아니라, 공유기 내부 서비스, DHCP, ARP, 브라우저 세션, WebSocket 주소, 서버 프로세스 상태까지 함께 영향을 받습니다.
따라서 현장에서는 공유기 LAN IP를 변경한 뒤 반드시 공유기와 주요 장비를 재부팅하고, PC의 IP / 게이트웨이 / WebSocket 서버 주소를 순서대로 확인하는 절차가 필요합니다.