FlClash 첫 설치 후 초기 설정 가이드: Windows·macOS·Android 공통 점검 항목과 자주 겪는 문제

1. 첫 실행 전: 설치 파일, 권한, 기존 프록시 확인

FlClash는 설정, 프록시 노드, 연결 상태를 관리하는 클라이언트이며, 실제 트래픽 전달은 통합된 mihomo 코어가 담당합니다. 설치가 끝났다는 것은 프로그램을 실행할 수 있다는 뜻일 뿐, 구독이 불러와졌거나 시스템 트래픽이 코어로 전달된다는 뜻은 아닙니다. 처음 설정할 때는 이 세 가지를 각각 확인하세요. 포트, DNS, 라우팅을 한꺼번에 변경하면 문제 원인을 파악하기 어려워집니다.

시작하기 전에 다른 프록시 클라이언트와 VPN을 종료하세요. 창을 닫는 것만으로는 트레이로 최소화될 수 있으니 트레이 메뉴에서 종료하고, 시스템 프록시가 이전 프로그램을 가리키고 있지 않은지도 확인하세요. 이 글에서는 혼합 포트 예시로 7890을 사용합니다. 모든 FlClash 버전의 기본값을 뜻하지는 않습니다. 실제 포트, 옵션 이름, 권한 절차는 설치된 버전에 표시된 내용을 따르세요.

운영체제별 설치 확인

• Windows: 「설정」→「시스템」→「정보」에서 시스템 종류를 확인하세요. x64와 ARM64 설치 파일은 기기 아키텍처에 맞게 선택해야 합니다. 먼저 일반 권한으로 실행하고, TUN 활성화나 서비스 설치, 가상 네트워크 어댑터 생성이 필요할 때만 클라이언트 안내에 따라 권한을 허용하세요.
• macOS: Apple 메뉴→「이 Mac에 관하여」에서 Apple 칩인지 Intel 프로세서인지 확인하세요. 앱을 「응용 프로그램」 폴더로 옮긴 뒤 실행하세요. 시스템에서 실행을 차단하면 먼저 앱의 출처를 확인하고, 「시스템 설정」→「개인정보 보호 및 보안」에서 구체적인 안내를 살펴보세요. 시스템 보안 기능 전체를 끄는 것은 설치 절차가 아닙니다.
• Android: APK 설치에 필요한 「출처를 알 수 없는 앱 설치」 권한은 실제로 사용하는 브라우저나 파일 관리자에만 허용하고, 설치가 끝나면 해제할 수 있습니다. 설정 메뉴 위치는 제조사마다 다르므로 시스템 설정에서 해당 항목을 검색하세요. 처음 VPN을 시작할 때 표시되는 시스템 승인 창은 앱 설치 권한과 별개입니다.

기존에 사용 중인 설정은 먼저 백업해 두세요. 구독 주소에 인증 토큰이 포함될 수 있으니 전체 링크나 QR 코드, 토큰이 포함된 로그 화면을 공개 게시판에 올리지 마세요.

2. 구독을 추가한 다음 현재 설정과 노드 확인

처음 실행한 뒤 클라이언트의 설정 관리 메뉴에서 구독 링크를 추가하거나 로컬 설정 파일을 가져오세요. 구독 주소를 붙여 넣을 때 앞뒤 공백과 줄바꿈을 확인하고, 기존 쿼리 매개변수는 그대로 유지하세요. 서비스 제공자의 로그인 페이지 주소를 구독 주소로 사용하면 안 됩니다. 구독은 사용자가 별도로 준비해야 하며, 클라이언트 설치 파일만으로 프록시 서비스를 이용할 수 있는 것은 아닙니다.

1. 설정 관리 화면에서 원격 구독을 추가하고 알아보기 쉬운 이름과 전체 주소를 입력한 뒤 저장하세요.
2. 한 번 업데이트를 실행하고 다운로드와 파싱이 끝날 때까지 기다리세요. 오류가 발생하면 먼저 오류를 해결하세요. TUN, DNS, 전역 모드를 연달아 바꾸지 마세요.
3. 가져온 설정을 현재 사용할 항목으로 지정하세요. 목록에 구독이 보인다고 해서 해당 구독이 적용된 것은 아닙니다.
4. 프록시 또는 정책 그룹 화면에서 노드와 그룹이 표시되는지 확인하세요. 수동 선택 그룹이라면 실제 노드를 하나 선택하고, 자동 선택 그룹이라면 사용 가능한 구성원이 있는지 확인하세요.

‘가져오기 성공’과 ‘연결 성공’ 구분하기

가져오기에 성공했다는 것은 받은 내용을 파싱할 수 있었다는 뜻입니다. 노드 만료, 인증 오류, 서버 연결 불가는 실제 연결을 시도한 뒤에야 드러날 수 있습니다. 반대로 구독 업데이트에 실패했다고 노드가 작동하지 않는 것은 아닙니다. 구독 업데이트 주소와 프록시 노드 주소는 서로 다른 네트워크 경로를 사용합니다.

응답 내용이 웹페이지, 로그인 안내 또는 접근 제한 페이지라면 HTTP 상태가 200이어도 유효한 설정이 아닙니다. 업데이트 오류에 표시된 형식과 파싱 정보를 확인한 뒤 구독 제공자에게 클라이언트 지원 여부를 문의하세요. 비공개 구독을 낯선 온라인 변환 사이트에 입력하지 마세요.

사용 가능한 프록시가 없는 상태에서 처음 구독을 가져올 때, 프록시가 있어야 접속할 수 있는 구독 주소를 사용하면 시작 단계에서 의존성이 생길 수 있습니다. 제공자가 안내한 접속 가능한 업데이트 주소를 사용하거나 기존의 신뢰할 수 있는 연결로 설정을 가져오세요. 아직 사용할 노드가 없는데 프록시를 반복해서 켜는 것으로는 이 문제를 해결할 수 없습니다.

3. 시스템 프록시와 TUN: 첫 테스트에서는 한 가지 경로만 사용

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱의 요청을 로컬 포트로 전달합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 적합합니다. 특정 설정에서는 둘을 함께 사용할 수 있지만, 처음 문제를 확인할 때는 한 경로만 활성화해 라우팅, DNS, 프록시 설정이 서로 미치는 영향을 줄이세요.

Windows·macOS: 먼저 브라우저로 기본 동작 확인

먼저 코어를 실행하고 TUN은 끈 상태에서 시스템 프록시를 활성화하세요. Windows에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시를 확인할 수 있습니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「프록시」에서 설정을 확인하세요. 메뉴 이름은 운영체제 버전에 따라 달라질 수 있지만, 확인할 항목은 프록시 호스트와 포트입니다.

브라우저 확장 프로그램, 브라우저 자체 프록시 설정, 기업 정책이 시스템 설정을 덮어쓸 수 있습니다. 첫 테스트에서는 프록시 확장 프로그램을 잠시 끄고 일반 브라우저 창에서 직접 연결이 예상되는 페이지와 프록시를 사용할 페이지를 각각 열어 보세요. 특정 브라우저에서만 실패한다면 클라이언트를 바로 재설치하기보다 해당 브라우저의 설정부터 확인하세요.

Android: VPN 아이콘이 표시돼도 모든 앱의 트래픽이 처리되는 것은 아닙니다

연결을 시작할 때 시스템 VPN 요청을 승인하고, 다른 VPN이 실행 중인지 확인하세요. 일반적으로 Android 사용자 프로필 하나에서는 활성 VPN 서비스를 하나만 유지할 수 있습니다. 다른 VPN이나 로컬 VPN 기반 필터링 앱이 FlClash와 충돌할 수 있습니다. 앱별 분할 설정을 사용 중이라면 테스트할 브라우저가 처리 대상에 포함됐는지도 확인하세요.

Android의 시스템 VPN 트래픽 처리 방식은 데스크톱의 시스템 프록시와 다릅니다. 데스크톱의 127.0.0.1:7890을 휴대폰 Wi-Fi 프록시에 그대로 입력해 컴퓨터를 가리키게 할 수는 없습니다. 휴대폰에서 127.0.0.1은 휴대폰 자체를 뜻합니다.

4. 혼합 포트 확인: 7890, 점유 프로세스, 수신 주소

mixed-port는 하나의 포트에서 HTTP 프록시와 SOCKS 프록시 연결을 모두 받습니다. 앱에서 사용하는 포트는 코어가 실제로 수신 중인 포트와 일치해야 합니다. 아래 내용은 필드의 의미를 보여 주는 예시일 뿐, 구독 설정을 그대로 덮어쓸 수 있는 전체 설정이 아니며 값을 직접 수정해야 한다는 뜻도 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

• mixed-port: 7890: 프록시를 수동으로 설정하는 앱에는 같은 포트를 지정해야 합니다. 포트를 7891로 바꾸면 브라우저, 터미널 등 포트를 직접 입력한 도구도 함께 변경하세요.
• allow-lan: false: 처음에는 이 기기에서만 사용할 수 있도록 LAN 접근을 꺼 둡니다. LAN 연결을 허용하려면 수신 주소, 방화벽, 인증도 함께 고려해야 합니다. 이 기기에서 연결이 안 된다는 이유로 LAN 접근을 바로 허용하지 마세요.
• mode: rule: 규칙에 따라 트래픽의 출구를 선택합니다. 트래픽 분할 방식을 제어하는 설정이며, 시스템 프록시를 켜거나 TUN 네트워크 어댑터를 만드는 기능은 아닙니다.
• log-level: info: 일반적인 실행 및 연결 확인에 사용하는 로그 수준입니다. 문제를 확인하려고 잠시 debug로 바꾼 경우, 확인이 끝나면 로그가 지나치게 쌓이지 않도록 원래 값으로 되돌리세요.

Windows: 포트를 점유한 프로세스 확인

시작 로그에 address already in use가 표시되면 PowerShell에서 아래 명령을 실행하세요. 첫 번째 명령은 수신 포트와 프로세스 ID를 표시하고, 두 번째 명령은 해당 ID를 프로세스 이름으로 확인합니다. 출력이 없다는 것은 확인 시점에 해당 TCP 포트의 수신 프로세스를 찾지 못했다는 뜻일 뿐, 코어가 정상적으로 실행 중임을 보장하지는 않습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

macOS: 로컬 수신 포트 확인

lsof -nP -iTCP:7890 -sTCP:LISTEN

프로세스가 어떤 프로그램에 속하는지 확인한 뒤 이전 클라이언트를 종료할지 포트를 바꿀지 결정하세요. 정체를 알 수 없는 프로세스를 바로 종료하지 마세요. 포트 충돌은 다른 프록시 프로그램이나 중복 실행된 코어 때문에 발생할 수 있습니다. 클라이언트 설정에서 포트를 바꿨다면 코어를 다시 시작한 후 실제 적용값을 확인하세요. 구독 업데이트가 직접 편집한 파일을 덮어쓸 수 있으므로, 설정을 계속 유지하려면 클라이언트가 지원하는 설정이나 오버라이드 기능을 사용하세요.

5. 규칙 모드, DNS, 연결 테스트의 올바른 순서

처음에는 규칙 모드를 사용하는 것이 좋습니다. 규칙은 보통 순서대로 확인하며, 처음 일치한 규칙이 트래픽 정책을 결정합니다. 이후 정책 그룹에서 사용할 노드를 선택합니다. 전역 모드에서도 선택한 정책과 노드가 정상이어야 하므로, 잘못된 노드 비밀번호나 포트, 전송 설정을 해결해 주지는 않습니다. 직결 모드로는 프록시 노드의 작동 여부를 확인할 수 없습니다.

지연 시간 숫자만 보지 말고 네 단계로 확인

1. 코어: 실행 후 설정 파싱 실패, 수신 실패, 권한 오류가 없는지 확인하세요. 화면에 창이 보인다고 코어가 정상적으로 실행 중인 것은 아닙니다.
2. 노드: 현재 정책 그룹의 노드를 대상으로 지연 시간을 테스트하세요. 결과는 테스트 주소와 시점에만 해당하며, 실제 다운로드 속도나 모든 대상 사이트의 연결 상태를 보여 주지는 않습니다.
3. 앱: 브라우저에서 요청을 보낸 뒤 클라이언트의 연결 목록이나 로그에서 대상 도메인, 적용된 규칙, 출구 정책을 확인하세요. 요청이 보이지 않으면 먼저 트래픽 처리 경로를 확인하세요.
4. 대상: 요청이 코어에 도달했는데 접속에 실패한다면 DNS 결과, 노드 연결 오류, 대상 서비스의 응답을 확인하세요. 페이지에 표시되는 403, 429, 연결 시간 초과는 서로 다른 문제입니다.

Windows에서는 HTTP 프록시를 명시적으로 지정해 비교 테스트를 할 수도 있습니다. 아래 명령은 혼합 포트가 실제로 7890인 경우에 사용하세요. macOS에서는 curl.exe를 curl로 바꾸면 됩니다. 예시 도메인이 규칙에 따라 직결로 처리되면 요청 성공은 로컬 프록시 진입점을 통과했다는 것만 의미하며, 프록시 노드가 정상이라는 뜻은 아닙니다.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

DNS는 먼저 구독과 클라이언트에서 사용하는 기존 설정을 유지하세요. mihomo의 Fake-IP 모드에서는 앱에 198.18.0.0/16 대역 등의 매핑 주소를 반환할 수 있으며, 이것만으로 DNS 응답이 오염됐다고 볼 수는 없습니다. TUN을 켠 뒤 DNS 조회에 실패하면 여러 공용 DNS를 한꺼번에 바꾸기보다 DNS 트래픽 처리, 상위 DNS 서버 연결, 다른 암호화 DNS 설정을 확인하세요.

브라우저의 보안 DNS 기능이 DNS 요청 경로를 바꿀 수 있지만, 반드시 연결 실패를 일으키는 것은 아닙니다. 비교 테스트에서 현재 트래픽 처리 방식과 충돌한다고 확인된 경우에만 잠시 끄고 다시 테스트하세요. 설정은 한 번에 하나씩 바꾸고 변경 전 값을 기록하세요.

6. 세 플랫폼에서 첫 실행 때 자주 겪는 문제

Windows: 시스템 프록시는 켰는데 명령줄은 여전히 직접 연결됨

일부 명령줄 도구는 Windows 시스템 프록시 설정을 읽지 않고 자체 프록시 옵션이나 환경 변수를 사용할 수 있습니다. 먼저 앞 절의 프록시 명시 지정 명령으로 확인한 뒤 해당 도구의 문서를 살펴보세요. 터미널이 트래픽 처리 대상이 아니라는 이유만으로 시스템 프록시 설정이 작동하지 않는다고 판단하지 마세요. TUN을 사용할 경우에는 브라우저가 정상적으로 연결되는지 먼저 확인한 다음 필요한 권한을 허용하고 라우팅을 테스트하세요.

macOS: 네트워크를 바꾸면 프록시가 작동하지 않거나 종료 후 인터넷에 연결할 수 없음

macOS 프록시 설정은 네트워크 서비스별로 적용됩니다. Wi-Fi에서 이더넷으로 전환했다면 현재 서비스의 프록시 설정을 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 끄고 직접 연결이 복구됐는지 확인하세요. 프로그램이 비정상 종료되면 시스템에는 로컬 포트를 가리키는 프록시 설정이 남아 있는데 코어는 중지되어 브라우저에 프록시 서버 연결 실패가 표시될 수 있습니다. 이때는 구독을 다시 가져오기보다 남은 프록시 설정을 정리하세요.

Android: 화면을 잠그면 연결이 끊기거나 일부 앱에서만 실패

화면이 켜져 있을 때는 작동하지만 잠시 잠근 뒤 연결이 끊긴다면 먼저 배터리 최적화와 백그라운드 실행 제한을 확인하세요. 「설정」→「앱」→ FlClash의 배터리 관련 메뉴에서 필요한 경우 백그라운드 실행을 허용하세요. 제조사에 따라 자동 시작 권한을 별도로 허용해야 할 수도 있습니다. 배터리 절약 제한과 노드 연결 시간 초과를 같은 문제로 보지 말고, 연결이 끊긴 시각과 클라이언트 로그를 비교하세요.

LAN 기기, 화면 전송, 업무 프로필 앱에서만 문제가 발생한다면 앱별 분할 설정, LAN 우회, 업무 프로필 격리를 확인하세요. LAN 대상에 연결하려면 올바른 로컬 라우팅이 필요합니다. 모든 트래픽을 원격 노드로 보내면 프린터, NAS, 사내 네트워크에 연결할 수 없게 될 수 있습니다. 먼저 대상 주소와 적용 규칙을 기록한 뒤 필요한 직결 규칙을 추가하세요.

7. 초기 설정 완료 후 확인 목록

초기 설정은 모든 스위치를 켜는 것이 아니라, 반복해서 확인할 수 있는 상태를 만드는 것으로 마무리해야 합니다. 원인을 설명할 수 있는 최소 설정을 유지하고, 이후 자동 시작, 앱별 분할, 사용자 지정 규칙을 차례로 추가하세요.

• 구독 업데이트를 완료했고 현재 설정을 선택했으며, 프록시 그룹에 사용할 수 있는 노드가 있습니다.
• 코어가 정상 실행 중이고 실제 수신 포트를 기록했으며, 포트 점유 오류가 없습니다.
• 데스크톱에서는 먼저 시스템 프록시를 테스트하고, TUN이 꼭 필요한 경우 권한, 라우팅, DNS를 별도로 확인합니다.
• Android에서 VPN 권한을 허용했고 테스트 앱이 트래픽 처리 대상에 포함되며, 백그라운드 실행 설정도 필요에 맞게 되어 있습니다.
• 직결 대상과 프록시 대상에 각각 연결해 보고, 연결 기록에서 사용된 정책을 확인할 수 있습니다.
• 연결을 끄면 일반 네트워크가 복구되고, 클라이언트를 다시 시작한 뒤에도 설정과 노드 선택이 예상대로 유지됩니다.
• 기본 연결이 안정된 뒤 구독 자동 업데이트와 시작 시 자동 실행을 켜세요. 여러 자동화 옵션을 한꺼번에 추가하지 마세요.

mixed-port, mode, 규칙 문법을 항목별로 확인하려면 설정 필드 참고를 살펴보세요. 설치 및 사용 방법은 입문 가이드에서 확인할 수 있습니다. 이후 문제가 생기면 발생 시각, 운영체제 버전, 클라이언트에 표시된 버전, 오류 원문, 마지막 설정 변경 내용을 기록해 두세요. 이런 정보가 반복해서 재설치하는 것보다 문제를 찾는 데 도움이 됩니다.