자주 묻는 질문

증상에 해당하는 항목부터 확인합니다. 먼저 현재 배포 방식과 실행 모드, 접속하려는 주소가 관리 진입점인지 게이트웨이 진입점인지 구분합니다.

관리 진입점이 열리지 않거나 로그인할 수 없음

관리 화면과 게이트웨이 진입점 구분

목적	진입점
설정 변경, 로그 확인 또는 모드 전환	fnOS 바탕화면의 Knock, Synology DSM 메인 메뉴의 Knock, OpenWrt의 서비스 → Knock 또는 Windows의 Knock Windows 관리 프로그램에서 로컬 관리 페이지 열기
인터넷, 도메인, 터널 또는 서비스 매핑 확인	실제 게이트웨이 포트나 해당 외부 도메인. 기본 게이트웨이 포트는 일반적으로 7999

OpenWrt의 기본 관리 포트는 7991이고 게이트웨이는 계속 7999입니다. Windows 관리 페이지는 127.0.0.1:7991로 엄격하게 제한되어 다른 기기에서 열 수 없습니다. 다른 배포의 포트는 포트 및 진입점을 참고합니다.

Windows 관리 페이지가 열리지 않음

먼저 Knock Windows 관리 프로그램을 열고 FnKnock 서비스 상태가 준비됨인지 확인한 뒤 “관리 패널 열기”를 클릭합니다. 새로 설치했을 때의 기본 주소는 http://127.0.0.1:7991/이며 프로그램을 설치한 Windows 호스트에서만 접속할 수 있습니다.

서비스가 준비 상태가 되지 않으면 먼저 기본 포트 다섯 개가 사용 중인지 확인합니다. %ProgramData%\FnKnock\config\runtime.json을 직접 편집하지 말고 관리 프로그램에서 포트를 변경해 저장합니다. 전체 절차는 Windows x86_64 배포를 참고합니다.

Synology에서 DSM 세션을 읽을 수 없다고 표시됨

현재 fn-knock 페이지를 닫고 DSM 로그인이 아직 유효한지 확인한 뒤 DSM 메인 메뉴에서 Knock을 다시 엽니다. Synology 관리 진입점은 DSM 바탕화면 창을 통해 세션을 읽습니다. launch.html이나 index.cgi를 직접 북마크에 추가하거나 열거나 내부 주소를 새 탭에 복사하면 필요한 DSM 컨텍스트가 누락될 수 있습니다.

administrators 그룹의 구성원만 관리 화면에 들어갈 수 있습니다. 그래도 실패하면 패키지 센터에서 fn-knock가 실행 중인지 확인한 뒤 DSM에 다시 로그인합니다. 7998을 대신 공개하지 않습니다. 전체 진입점과 포트 설명은 Synology DSM 7 배포를 참고합니다.

관리 패널에 저장소 오류가 표시됨

현재 버전은 SQLite를 사용하며 새로 설치할 때 Redis가 필요하지 않습니다.

• 새로 설치한 경우: 데이터 디렉터리 권한, 포트 충돌 및 서비스 로그를 확인합니다.
• 이전 Redis 버전에서 업그레이드한 경우: 기존 Redis 데이터 볼륨을 유지하고 Docker 배포의 마이그레이션 절차를 따릅니다.
• OpenWrt: /etc/fn-knock/gateway와 /var/lib/fn-knock가 여전히 존재하는지 확인합니다.

새로 설치할 때 빈 Redis를 따로 만들지 않습니다. 이전 데이터의 마이그레이션을 마치고 관리 패널이 정상인지 확인한 뒤 기존 Redis 서비스와 데이터 볼륨을 제거합니다.

관리 비밀번호를 잊음

관리 비밀번호는 방문자 인증 자격 증명과 별개입니다. 배포 방식에 따라 로컬 콘솔이나 컨테이너에서 초기화를 실행하고 데이터 디렉터리는 삭제하지 않습니다.

• Docker: Docker 배포의 관리 비밀번호 복구 설명을 참고합니다.
• OpenWrt: OpenWrt 배포를 참고합니다.
• fnOS FPK: 먼저 fnOS 바탕화면에서 Knock에 다시 들어갑니다.
• Windows: 먼저 Knock Windows 관리 프로그램에서 “관리 비밀번호 초기화”를 클릭합니다. 관리 프로그램을 열 수 없다면 애플리케이션 설치 디렉터리에서 관리자 PowerShell로 .\fn-knock-service.exe reset-panel-password를 실행합니다.

관리는 정상이지만 외부 네트워크에서 접근할 수 없음

관리 패널은 열리지만 외부 도메인은 계속 시간 초과됨

관리 패널이 정상이라는 것은 관리 서비스가 실행 중이라는 의미일 뿐입니다. 다음 순서로 확인합니다.

1. 현재 네트워크 토폴로지에 맞게 공인 IP 직접 연결 또는 리버스 프록시 모드를 선택했는지 확인합니다.
2. 외부 트래픽이 관리 포트가 아닌 실제 게이트웨이 포트에 도달하는지 확인합니다. 기본값은 일반적으로 7999입니다.
3. DNS가 현재 공인 IP 또는 터널 진입점을 가리키는지 확인합니다.
4. 공인 IP로 직접 연결한다면 라우터 포트 포워딩과 호스트 방화벽이 접근을 허용하는지 확인합니다.
5. 리버스 프록시 모드라면 터널이 연결되어 있고 올바른 로컬 게이트웨이를 가리키는지 확인합니다.
6. 요청 로그에 해당 요청이 표시되는지 확인합니다.

인터넷 인바운드를 구성할 수 없다면 리버스 프록시 모드: 서브도메인 라우팅을 사용합니다.

LAN 또는 인터넷에서 Windows의 7999에 접근할 수 없음

현재 Windows 버전의 7999는 기본적으로 모든 IPv4/IPv6 인터페이스에서 수신 대기합니다. 접근할 수 없다면 게이트웨이가 루프백에서만 수신하기 때문이 아니라 인바운드 경로가 아직 연결되지 않은 경우가 일반적입니다. 설치 프로그램이 만드는 FnKnock Gateway 인바운드 프로그램 규칙은 Windows의 ‘도메인’과 ‘개인’ 네트워크 프로필에만 적용되며 ‘공용’ 네트워크에는 적용되지 않습니다.

경로를 따라 Windows의 현재 네트워크 프로필과 서드파티 보안 소프트웨어, 라우터 또는 NAT 포워딩, IPv6 방화벽 및 ISP의 인바운드 허용 여부를 확인합니다. 관리 패널 7991은 계속 로컬 기기로 엄격히 제한되며 인터넷 오리진으로 사용할 수 없습니다. Windows는 로그인 상태에 따른 동적 방화벽 관리나 직접 연결 접근 허용을 지원하지 않습니다.

같은 Windows 호스트에서 터널이나 리버스 프록시를 직접 실행한다면 127.0.0.1:7999를 오리진으로 사용하는 것을 권장합니다. 다만 해당 프로세스는 fn-knock가 관리하지 않으므로 원래 Host와 실제 클라이언트 IP를 보존하도록 직접 구성합니다.

fnOS 네이티브 FPK의 7999가 다른 포트로 리디렉션됨

fnOS의 HTTPS 연결 강제가 요청이 fn-knock에 도달하기 전에 리디렉션을 수행할 수 있습니다.

fnOS 시스템 설정 → 보안 → 포트 설정 → 설정으로 이동해 HTTPS 연결 강제를 끈 뒤 7999를 다시 테스트합니다.

자동 HTTPS 시작 실패

자동 HTTPS는 현재 배포에 해당 기능이 표시되고 호스트에 실제 인바운드 경로와 80번 포트가 있을 때만 사용할 수 있습니다. Docker, OpenWrt 및 Synology DSM 7 SPK에는 이 스위치가 없습니다. 다음 사항을 확인합니다.

• 다른 서비스가 80번 포트를 사용 중인지 확인합니다.
• 현재 권한으로 낮은 번호의 포트에서 수신 대기할 수 있는지 확인합니다.
• fnOS 포트 리디렉션이나 다른 앞단 진입점과 충돌하는지 확인합니다.
• SSL 인증서가 설정되었는지 확인합니다.

자동 HTTPS는 인증서 발급을 대신하지 않습니다. Windows의 7999가 기본적으로 모든 인터페이스에서 수신하더라도 이 기능을 켠다고 방화벽, 라우터/NAT 또는 ISP 인바운드 제한이 자동으로 열리지는 않습니다. Docker, OpenWrt 및 Synology에서는 앞단 프록시, 엣지 플랫폼 또는 게이트웨이 외부에서 TLS를 종료합니다. TLS 인증서를 참고합니다.

로그인하지 않아도 서비스 포트에 바로 접근할 수 있음

fn-knock를 우회하는 진입점이 있습니다. 라우터 포트 포워딩, 호스트 방화벽, IPv6 방화벽 및 앞단 프록시를 확인하고 서비스로 직접 연결되는 인터넷 공개 규칙을 닫습니다.

직접 연결 접근 허용에서는 인증 게이트웨이만 공개하고 로그인 후 현재 인터넷 출구 IP를 임시로 허용합니다. Docker와 Windows에서는 fn-knock가 호스트 방화벽을 관리할 수 없습니다.

도메인, 서브도메인 또는 터널이 작동하지 않음

접근 방식 선택 기준

조건	방식
인터넷 인바운드가 있고 주로 웹 서비스에 접근	공인 IP 직접 연결: 서브도메인 라우팅
인터넷 인바운드가 없음	리버스 프록시 모드: 서브도메인 라우팅
SSH, 원격 데스크톱 같은 원본 포트를 보호해야 함	원본 포트 접근: 직접 연결 접근 허용
이전 경로 접두사를 반드시 유지해야 함	리버스 프록시 모드의 경로 모드이며 호환 목적으로만 사용

먼저 네트워크 토폴로지에 따라 진입점을 선택하고, Host, 경로 또는 TCP/UDP에 따라 라우팅 방식을 선택한 뒤 서비스의 접근 정책을 설정합니다.

터널 모드의 DDNS 필요 여부

일반적으로 필요하지 않습니다.

• FRP는 서버 주소와 외부 포트를 사용합니다.
• Cloudflared는 Cloudflare Tunnel에 연결된 도메인을 사용합니다.

터널 진입점 자체가 동적 공인 주소에 의존할 때만 해당 진입점에 DDNS를 설정합니다.

FRP와 cloudflared 선택 기준

• 기존 FRP 서버가 있고 인터넷 공개 포트와 트래픽을 직접 제어하려면 FRP를 사용합니다.
• Cloudflare를 이미 사용하고 있으며 공인 서버의 유지 관리를 줄이려면 Cloudflared를 사용합니다.

두 방식 모두 인증 도메인과 서비스 도메인을 fn-knock 게이트웨이로 전달하고 원래 Host를 보존하도록 구성합니다. NAT 통과 및 터널을 참고합니다.

cloudflared 오리진 프로토콜 선택

• fn-knock 로컬 게이트웨이에 인증서가 설정되지 않은 경우: http://...:<실제 게이트웨이 포트>를 사용합니다.
• 로컬 게이트웨이에 유효한 인증서가 설정되었고 Cloudflared가 해당 인증서를 신뢰하는 경우: https://...:<실제 게이트웨이 포트>를 사용합니다.

Cloudflared와 fn-knock가 서로 다른 컨테이너에 있으면 localhost는 잘못된 컨테이너를 가리킵니다. 서로 통신할 수 있는 컨테이너 이름이나 LAN 주소를 사용합니다. Cloudflared 터널을 참고합니다.

서브도메인에서 잘못된 서비스가 열림

다음 사항을 확인합니다.

1. 앞단 프록시나 터널이 원래 Host를 보존하는지 확인합니다.
2. 루트 도메인과 서브도메인 매핑이 일치하는지 확인합니다.
3. 중복 매핑이나 폴백 매핑이 먼저 일치하는지 확인합니다.
4. 인터넷 오리진이 실제 게이트웨이 포트를 가리키는지 확인합니다.

관리 진입점을 서비스 오리진으로 사용할 수 없습니다.

경로 매핑에서 리소스 404 또는 로그인 루프가 발생함

업스트림 서비스가 경로 접두사, 리디렉션, 쿠키 또는 WebSocket을 올바르게 처리하지 못하고 있습니다. 새 설정은 독립된 서브도메인으로 이전합니다. 업스트림에서 접두사 배포를 명시적으로 지원할 때만 경로 모드를 계속 사용합니다.

서비스 검색에서 서비스를 찾지 못함

먼저 대상이 fn-knock 실행 환경에서 접근할 수 있는 로컬 IPv4 HTTP 서비스인지 확인합니다. 서비스 검색은 인터넷, IPv6, 도메인 또는 HTTP가 아닌 프로토콜을 스캔하지 않습니다. Docker에서 127.0.0.1은 컨테이너 자체만 가리킵니다.

스캔 CIDR을 대상의 실제 네트워크 대역으로 좁히고 16개 CIDR과 총 1024대의 호스트를 넘지 않는지 확인한 뒤 fn-knock 실행 환경에서 대상 포트에 직접 접근합니다. TCP 포트가 열려 있어도 HTTP로 분석할 수 없다면 후보가 생성되지 않습니다. 전체 범위와 강도 설정은 서비스 검색 및 일괄 등록을 참고합니다.

EdgeOne 또는 ESA에서 로그인 루프나 페이지 오류가 발생함

다음 사항을 확인합니다.

• 오리진이 fn-knock의 실제 게이트웨이 포트를 가리키는지 확인합니다.
• 서브도메인 매핑에서 해당 플랫폼 지원을 활성화했는지 확인합니다.
• 캐시를 끄고 WebSocket을 켰는지 확인합니다.
• 실제 클라이언트 IP 요청 헤더가 올바르게 전달되는지 확인합니다.
• 듀얼 스택 오리진이 요청을 서로 다른 진입점으로 보내는지 확인합니다.

자세한 설정은 Tencent Cloud EdgeOne 및 Alibaba Cloud ESA를 참고합니다.

홈 Wi-Fi에서도 인터넷 경로를 계속 사용함

클라이언트가 계속 공인 DNS 결과를 사용하고 있습니다. fnOS 네이티브 FPK나 OpenWrt에서 Smart Connect를 사용할 때는 다음 사항을 확인합니다.

• 시스템 설정 → 기능 → Smart Connect가 활성화되어 있는지 확인합니다.
• 기기의 LAN IP가 올바른지 확인합니다.
• 라우터의 DHCP DNS 또는 클라이언트 DNS가 fn-knock 실행 기기를 가리키는지 확인합니다.
• 클라이언트의 DNS 캐시를 새로 고쳤는지 확인합니다.

OpenWrt에서는 시스템에 dnsmasq가 설치되어 실행 중인지와 기본 설정에 /etc/dnsmasq.d/가 포함되어 있는지도 확인합니다. 페이지의 자동 설치는 apt-get을 호출하므로 OpenWrt에서 사용할 수 없습니다. Smart Connect는 서브도메인 모드에서 LAN DNS를 최적화할 때만 사용하며 공인 DNS는 변경하지 않습니다. Docker에서는 이 기능을 제공하지 않습니다. Smart Connect를 참고합니다.

로그인 또는 세션 문제

TOTP, 비밀번호, 패스키 및 QQ 선택 기준

• TOTP: 기본 로그인 방식이자 패스키, QQ 및 다른 외부 계정을 연결하는 기준입니다. 사용할 수 있는 복구 수단을 반드시 유지합니다.
• 계정 비밀번호: TOTP 인증기를 사용하기 어려운 구성원에게 적합합니다.
• 패스키: 기존 TOTP 자격 증명에 편리한 로그인 방식을 추가합니다.
• QQ: QQ 계정 하나를 기존 TOTP에 연결해 빠른 로그인을 제공하고 해당 TOTP의 서비스 범위를 상속합니다. 독립된 사용자가 아닙니다.

계정 비밀번호 로그인 모드로 전환하면 로그인 페이지에 패스키, QQ 또는 다른 외부 계정 진입점이 표시되지 않습니다. 인증 및 로그인과 QQ 빠른 로그인 연결을 참고합니다.

로그인 페이지의 봇 방지 설정

시스템 설정 → 보안 인증으로 이동합니다. PoW와 Turnstile의 차이점은 보안 인증을, Cloudflare 설정은 Turnstile을 참고합니다.

“로그인 상태 유지”와 세션 유효 시간

세션 유효 시간은 시스템 설정 → 세션에서 설정합니다. “로그인 상태 유지”를 선택하면 장기 세션 유효 시간을 사용합니다. IP 접근 권한을 세션에 맞추도록 설정했다면 해당 권한도 함께 연장됩니다.

개인 소유의 신뢰할 수 있는 기기에서만 장기 세션을 사용합니다.

TOTP를 삭제한 뒤 다른 로그인 방식이 작동하지 않음

TOTP를 삭제하면 연결된 패스키, QQ 및 다른 외부 계정 연결도 함께 무효화됩니다. 삭제하기 전에 사용할 수 있는 다른 자격 증명이 있는지 확인합니다. 삭제한 뒤에는 관련 로그인 방식을 다시 연결합니다.

로그인에 성공해도 로그인 페이지로 돌아옴

다음 순서로 확인합니다.

1. 인증 도메인과 서비스 도메인이 같은 공개 프로토콜을 사용하는지 확인합니다.
2. 루트 도메인, 쿠키 범위 및 패스키 RP ID가 일치하는지 확인합니다.
3. 브라우저에서 쿠키를 차단하는지 확인합니다.
4. 엣지 플랫폼에서 로그인 응답을 캐시하는지 확인합니다.
5. 앞단 프록시가 올바른 Host, X-Forwarded-Host 및 X-Forwarded-Proto를 전달하는지 확인합니다.
6. 시스템 시간이 정확한지 확인합니다.

같은 인증 페이지나 같은 대상에서 루프가 계속되면 시스템이 자동 복귀를 일시 중지합니다. 이때 원래 서비스 Host에서 다시 접근을 시작하고 인증 콜백 주소를 반복해서 새로 고치거나 복사하지 않습니다.

fnOS 클라이언트에 주소를 직접 입력한 뒤 로그인할 수 없음

fnOS 클라이언트에서 웹 인증 리디렉션을 처리하고 쿠키를 재사용할 수 있는지는 클라이언트 버전에 따라 다릅니다. 브라우저 세션이 네이티브 클라이언트에 자동으로 공유된다고 보장할 수 없습니다.

• 서브도메인 또는 리버스 프록시 모드: 먼저 모바일 브라우저에서 같은 외부 도메인을 열어 로그인합니다.
• 직접 연결 접근 허용: 먼저 브라우저에서 실제 게이트웨이 포트를 연 뒤 fnOS 클라이언트로 돌아가 원본 주소에 연결합니다.

전체 절차는 fnOS 클라이언트 사용을 참고합니다.

네트워크를 바꾼 뒤 갑자기 접근 권한이 사라짐

모바일 네트워크, 프록시 및 가정용 인터넷 회선은 인터넷 출구 IP를 바꿀 수 있습니다. 인증 진입점을 다시 열어 로그인하고 시스템 설정 → 세션에서 IP 변경 이력을 확인합니다.

이 이력은 세션이 기존 IP에서 새 IP로 이동한 과정을 기록하며 일반 요청 로그가 아닙니다.

세션 옆 fnOS 아이콘의 의미

해당 로그인 세션에 fnOS 토큰이 연결되었다는 뜻입니다. fnOS 클라이언트나 웹 페이지에서 현재 로그인을 계속 재사용할 때 주로 표시됩니다. 세션을 강제 종료하거나 로그아웃하거나 세션이 만료되면 연결된 토큰도 무효화됩니다. 세션 관리를 참고합니다.

라우팅, 보안 또는 로그 문제

로그인에 성공해도 허용 목록에 없다고 표시됨

먼저 해당 Host가 이전 strict_whitelist 규칙을 상속했는지 확인합니다.

• 로그인 필요 끄기: 현재 로그인 우선 매핑은 공개 접근을 허용하며 로그인과 허용 목록을 검사하지 않습니다. 이전 엄격한 허용 목록 매핑에는 해당하지 않습니다.
• 로그인 필요 켜기: 수동 출발지 접근 권한으로 독립적으로 허용할 수 있습니다. 자동 IP 접근 권한은 일반적으로 같은 출발지의 계속된 접근을 허용하지만 이미 적용된 서비스 범위 거부를 무시하지는 않습니다. 사용할 수 있는 출발지 접근 권한이 없을 때 세션을 확인합니다.
• 이전 엄격한 허용 목록 규칙: 로그인 필요를 꺼도 반드시 공개되는 것은 아닙니다. 수동으로 만들거나 로그인 후 자동 생성된 유효 출발지 접근 권한 레코드만 기준으로 판단하며 브라우저 세션 쿠키만으로는 출발지 조건을 대신할 수 없습니다.

현재 Host 편집 화면에는 엄격한 허용 목록을 선택하는 항목이 없습니다. 이전 규칙이 있다면 현재 인터넷 출구 IP의 수동 또는 자동 접근 권한 레코드를 확인합니다. 수동 출발지만 허용하려면 로그인 후 자동 IP 접근 허용을 끄고 남아 있는 자동 레코드를 확인합니다. 이 규칙을 사용하지 않으려면 전체 매핑 설정을 먼저 기록한 뒤 현재 화면에서 매핑을 다시 만듭니다. 로그인 필요만 끄는 것으로는 공개되지 않습니다.

fnOS 공유 링크가 차단됨

fnOS 공유 우회는 서브도메인 라우팅과 리버스 프록시 모드에서 사용할 수 있으며 직접 연결 모드에는 적용되지 않습니다. /s/... 요청에 실제로 선택된 라우트가 fnOS를 가리키는지 확인합니다. 다른 경로 규칙이나 잘못된 기본 라우트가 요청을 가져가면 우회가 동작하지 않습니다. fnOS 공유 우회를 참고합니다.

요청 로그 활성화

시스템 설정 → 로그에서 활성화합니다. 활성화하면 사이드바에 요청 로그가 표시되며 일치한 Host, 업스트림 및 응답 상태를 날짜별로 확인할 수 있습니다. 요청 로그를 참고합니다.

CPU 또는 메모리 사용량이 높지만 이벤트 센터에 경고가 없음

현재 기본값에서는 사용률이 80% 이상으로 약 30초 동안 유지되어야 경고가 발생합니다. 짧은 순간의 급증은 바로 이벤트가 되지 않으며 복구 이벤트도 60%까지 계속 낮아져야 발생합니다. Windows는 시스템 리소스 모니터링을 제공하지 않습니다. Docker의 값은 컨테이너 실행 환경에 표시되는 리소스 범위를 기준으로 해석합니다.

먼저 플랫폼 기능, 이벤트 시스템 및 리소스 이벤트가 정상인지 확인한 뒤 “리소스 이벤트 발생 조건”과 “알림 규칙 트리거 조건”을 구분합니다. 후자는 기존 이벤트를 언제 보낼지만 결정하며 샘플링 임계값은 바꾸지 않습니다. 이벤트 센터 및 알림을 참고합니다.

일반 차단 목록과 스캐너 차단 목록의 차이

• 스캐너 차단 목록: 인증되지 않은 비정상 경로 탐지를 기준으로 자동 차단합니다.
• 일반 차단 목록: 관리자가 로그 또는 차단 목록 페이지에서 IP를 명시적으로 차단합니다.

일반 차단 목록에는 정확한 IPv4 또는 IPv6 주소만 추가할 수 있으며 CIDR은 사용할 수 없습니다. 네트워크 대역이나 지역을 제한하려면 게이트웨이 접근 범위를, 비정상 IP 하나를 차단하려면 일반 차단 목록을 사용합니다.

HTTPS 조기 구성의 필요성

HTTPS는 로그인 자격 증명과 세션 쿠키를 보호하며 패스키를 정상적으로 사용하기 위한 조건이기도 합니다. 공인 도메인과 FRP 및 Cloudflared의 공개 진입점에는 모두 신뢰할 수 있는 인증서를 사용합니다. TLS 인증서를 참고합니다.

설치, 업그레이드 또는 데이터 문제

OpenWrt 설치 및 업그레이드 방법

OpenWrt는 아키텍처와 일치하는 .ipk 및 .apk 패키지를 지원합니다. 설치 후 진입점은 서비스 → Knock입니다.

업그레이드할 때는 새 버전의 소프트웨어 패키지를 설치합니다. 웹 관리 패널 FPK 업데이트는 OpenWrt에 적용되지 않습니다. 정상 업그레이드에서는 /etc/config/fn-knock와 /var/lib/fn-knock가 유지됩니다. 전체 명령은 OpenWrt 배포를 참고합니다.

Docker 업그레이드 후 데이터가 비어 있음

먼저 추가 쓰기 작업을 중지하고 기존 데이터 볼륨이 남아 있는지 확인합니다. 현재 버전은 SQLite를 사용하며 이전 Redis 버전에서 업그레이드할 때만 Redis에서 SQLite로 마이그레이션합니다.

기존 볼륨을 삭제하거나 빈 볼륨으로 원래 마운트를 덮어쓰지 말고 새 설치에 Redis를 따로 추가하지도 않습니다. Docker 배포의 백업 및 마이그레이션 절차에 따라 복구합니다.

.knock 백업을 가져올 수 없거나 가져온 뒤 경고가 표시됨

파일이 원래 .knock 확장자를 유지하고 크기가 128 MiB를 넘지 않는지, 내보낸 버전이 현재 인스턴스보다 높지 않은지 확인합니다. 대상 버전에는 오류 메시지에 표시된 지원 범위 안의 버전만 사용합니다. 아카이브 JSON을 수정해 버전을 위조하지 않습니다.

가져오기 성공 후 표시되는 경고는 설정 항목은 복원되었지만 게이트웨이, WAF, SSL 등의 런타임 동기화 단계 중 하나가 실패했다는 뜻입니다. 전체 가져오기가 자동으로 롤백되었다는 의미가 아닙니다. 관리 진입점을 유지한 채 경고를 하나씩 확인하고 해당 설정을 직접 다시 저장합니다. 같은 파일을 먼저 반복해서 가져오지 않습니다. 백업, 복원 및 데이터 정리를 참고합니다.

Windows 업데이트 또는 데이터 정리 방법

Knock Windows 관리 프로그램이나 시스템 트레이의 “업데이트 확인”에서 Windows 업데이트를 설치합니다. 웹 페이지의 버전 및 업데이트에는 버전과 설명만 표시됩니다. 업그레이드하기 전에 백업을 내보냅니다. 시작에 실패하면 설치 프로그램이 이전 버전의 프로그램과 데이터를 복원합니다.

Windows 프로그램을 제거한 뒤에도 복구를 위해 %ProgramData%\FnKnock가 유지되며 SQLite, 인증서 및 설정이 포함되어 있습니다. 더 이상 복구할 필요가 없다는 것을 확인한 뒤에만 관리자 권한으로 해당 디렉터리를 별도로 삭제합니다.

업데이트 후 기능 진입점이 이전 문서와 다름

먼저 현재 배포 환경의 기능을 확인합니다.

기능	fnOS FPK	Docker	OpenWrt	Linux 서비스	Synology DSM 7 SPK	Windows x86_64
호스트 방화벽 및 직접 연결 접근 허용	지원	미지원	지원	미지원	미지원	미지원
자동 HTTPS	지원	미지원	미지원	지원, 80번 포트와 인바운드 경로 필요	미지원	지원, 방화벽, NAT 및 인바운드 경로를 별도로 연결해야 함
ACME DNS-01	지원	지원	지원	지원	지원	지원, Let's Encrypt로 고정된 내장 클라이언트 사용
Smart Connect	지원	미지원	지원, 기존 dnsmasq와 설정 포함에 의존	미지원	미지원	미지원
SSH 보안	지원	미지원	미지원	미지원	미지원	미지원
웹 터미널	지원	미지원	미지원	지원, tmux 필요	미지원	미지원
내장 FRP / Cloudflared	지원	지원	지원	지원	지원	미지원
업데이트 설치	웹 페이지에서 업데이트	새 이미지 가져오기	IPK / APK 설치	sudo knock update	DSM 패키지 센터 / SPK	Windows 관리 프로그램에서 처리

배포 환경별 범위와 권장 진입점은 배포 및 접근 방식 선택을 참고합니다.