소스의 해결 과정은 매우 명확합니다. 이는 모든 애플리케이션에 영향을 미친 Docker 오류가 아니었습니다. 사용자는 Tailscale을 exit 노드 방식으로 설정했고, 그 후 로컬 네트워크에서도 Jellyfin 및 다른 앱 URL이 작동하지 않았습니다. 이후 Tailscale을 제거하고 ZimaOS LAN IP를 통해 연결하자 모든 것이 다시 작동한다고 보고했습니다.
이 동작은 현재 Tailscale 문서의 내용과 일치합니다. 클라이언트가 exit 노드를 사용하면 로컬 네트워크 액세스 허용이 활성화되어 있지 않은 한 로컬 LAN 액세스가 기본적으로 비활성화됩니다. 애플리케이션을 다시 설치하거나 Docker를 재시작하기 전에 라우팅 테이블과 클라이언트가 의도적으로 exit 노드를 통해 트래픽을 전송하고 있는지 확인하세요.
앱에 직접 연결하는 포트도 작동하지 않음
사용자는 애플리케이션 포트에 직접 접속해 보았지만 Tailscale을 통한 연결을 제외하면 아무것도 작동하지 않는다고 말했습니다. 이는 유용한 단서입니다. 서로 관련 없는 여러 컨테이너에 동시에 연결할 수 없게 되었다면, 각 애플리케이션이 개별적으로 고장 났다고 가정하기 전에 공유 네트워크 및 라우팅 계층을 먼저 점검하세요.
실패한 Docker 재시작 명령은 문제의 핵심이 아니었음
ZimaOS는 온라인 튜토리얼에 나오는 모든 서비스 관리 명령이 적용되는 일반적인 Debian 시스템이 아닙니다. 모든 앱이 작동하지 않는다면 먼저 컨테이너가 실제로 실행 중인지, 호스트 또는 LAN에서 컨테이너가 공개한 포트에 연결할 수 있는지 확인하세요.
Exit 노드는 클라이언트의 기본 경로를 변경함
Tailscale exit 노드는 일반 인터넷 트래픽을 다른 tailnet 장치를 통해 라우팅합니다. 현재 Tailscale 문서에는 exit 노드를 사용하는 동안 로컬 네트워크 액세스가 기본적으로 꺼져 있다고 명시되어 있습니다.
현재 Tailscale exit 노드 동작을 참조하세요.
두 가지를 동시에 사용하려면 로컬 네트워크 액세스 허용을 활성화
현재 Tailscale 클라이언트에는 로컬 네트워크 액세스 허용 옵션이 있습니다. CLI 기반 클라이언트에서는 exit 노드 LAN 액세스 플래그를 사용해 동일한 설정을 구성할 수 있습니다.
로컬 네트워크를 신뢰할 수 있는 경우에만 이 옵션을 활성화하세요.
문제를 분리하려면 Exit 노드 비활성화
빠른 진단 방법은 활성 exit 노드로 없음을 선택한 다음 ZimaOS LAN IP와 앱 포트 하나를 다시 시도하는 것입니다. 로컬 액세스가 즉시 복구된다면 Docker가 아니라 라우팅 설정을 우선적으로 조사해야 합니다.
원 게시자는 Tailscale을 제거한 후 복구를 확인함
사용자는 Tailscale 설정을 통해 연결했을 때 컴퓨터가 라우터 및 로컬 IP 경로에서 연결이 끊겼다고 말했습니다. Tailscale을 제거하고 로컬 IP를 사용하자 모든 앱이 다시 작동했습니다.
이는 소스에서 확인된 복구 결과이지만, 사용자는 문제를 일으킨 정확한 exit 노드 플래그를 기록하지 않았습니다.
더 나은 문제 해결 순서
- LAN IP를 사용해 ZimaOS 대시보드를 직접 엽니다.
- 앱 포트 하나가 로컬에서 작동하는지 확인합니다.
- 활성화된 Tailscale exit 노드를 비활성화합니다.
- 로컬 앱 액세스를 다시 시도합니다.
- 그래도 포트에 연결할 수 없을 때만 Docker 및 앱 로그를 확인합니다.
모든 앱에서 Service Unavailable이 발생할 때의 FAQ
앱을 다시 설치하면 소스의 문제가 해결되었나요?
아니요. 문제가 된 Tailscale 라우팅 상태를 제거한 후에야 앱이 다시 작동하기 시작했습니다.
Tailscale exit 노드가 로컬 LAN 액세스를 차단할 수 있나요?
예. 현재 Tailscale 문서에 따르면 exit 노드를 사용하는 동안 사용자가 로컬 네트워크 액세스를 활성화하지 않으면 LAN 액세스가 기본적으로 비활성화됩니다.
Docker 자체가 고장 났다는 사실이 확인되었나요?
아니요. 소스의 해결 과정은 Docker 데몬 오류가 아니라 라우팅 문제를 가리킵니다.
