Windows 11에 FlClash 설치 후 구독 가져오기와 시스템 프록시 첫 설정: mihomo 그래픽 클라이언트 입문 (2026)

1. FlClash와 mihomo 코어가 의미하는 것

FlClash는 데스크톱에서 흔히 보는 Clash 그래픽 클라이언트 중 하나이며, 화면은 Flutter로 짜였지만 밑에서는 mihomo 계열 코어가 돌아갑니다. 사용자가 설정 창에서 노드를 고르고 규칙 모드를 바꿀 때 실제로는 활성 구성 YAML이 코어에 넘어가고, DNS·규칙 프로바이더·프록시 그룹이 그대로 적용됩니다. 그래서 「앱 이름은 FlClash인데 검색은 Clash로 한다»는 식의 혼용이 자연스럽고, 로그에 나오는 필드 이름도 다른 mihomo 패널과 크게 다르지 않습니다.

Windows 11에서 처음 켤 때 중요한 축은 두 가지입니다. 하나는 OS가 HTTP·HTTPS 프록시 자리를 어디에 두는가 하는 시스템 프록시 경로이고, 다른 하나는 가상 네트워크 카드로 전체 IP 트래픽을 잡는 TUN 계열입니다. 이 글은 검색 의도에 맞춰 구독 가져오기 뒤 시스템 프록시까지를 본문 중심에 두고, TUN은 필요할 때만 넘어가는 보조 축으로 설명합니다. UI 라벨은 릴리스마다 조금씩 바뀔 수 있으니 「시스템 프록시」「프로필」「구독」「코어 시작」 같은 의미 단위로 기능을 짝지으면 금방 적응합니다.

2. 설치와 첫 실행: 아키텍처·스마트스크린·방화벽

설치 전에 설정 앱에서 시스템 종류를 확인해 x64와 arm64 중 맞는 빌드를 고릅니다. Copilot+ PC처럼 ARM 실리콘이면 amd64 패키지를 억지로 쓰면 실행 단계에서 막히므로 여기부터 맞추는 편이 시간을 아낍니다. 인스톨러나 포터블 배포는 채널에 따라 다르지만, 첫 실행에서 뜨는 Microsoft 스마트스크린 흐름 자체는 다른 Clash GUI와 비슷합니다. 발행자 정보를 확인한 뒤 필요한 단계까지 진행해야 실행이 허용됩니다.

설치 직후 Windows Defender 방화벽이 로컬 액세스를 물으면, 사설망에서 허용하는 경우가 많습니다. 로컬 루프백과 구독 갱신·업데이트 요청이 막히면 「연결은 됐는데 갱신만 실패» 같은 증상으로 이어집니다. 회사 단말은 백신 HTTPS 검사나 제로트러스트 에이전트 때문에 첫 다운로드만 지연처럼 보일 수 있으니, 증상이 네트워크 전반이 아니라 특정 단계에만 걸리는지 나눠 봅니다.

패키지는 운영 측이 안내하는 경로에서 받는 습관이 안전합니다. 다운로드 허브처럼 정리된 페이지를 쓰면 변조 파일이 끼어 들 위험을 줄이고, 이후 처음 설정에서 드라이버나 업데이트 단계가 꼬일 때도 원인 추적이 쉽습니다. 과거 다른 Clash 계열을 깔았다가 남은 가상 어댑터가 있으면 장치 관리자에서 상태를 한 번 훑는 것도 좋습니다.

3. 구독 가져오기와 프로필 활성화

구독 가져오기는 제공자 대시보드에서 복사한 URL을 프로필·구독 입력 칸에 붙여 넣고 갱신을 눌러 노드 목록을 채우는 과정입니다. FlClash도 화면 구석의 프로필 목록에서 하나를 활성화한 뒤, 테스트 노드를 골라 응답을 확인하는 흐름이 일반적입니다. 이름이 「프로필」「구성」「Config」처럼 바뀌어도 의미는 같고, 중요한 것은 지금 켜 둔 파일이 코어에 실제로 로드됐는지입니다.

갱신이 실패하면 브라우저에서는 같은 URL이 열리더라도 클라이언트만 TLS·DNS·403에서 멈출 수 있습니다. 이때는 로그 문자열을 함께 보는 편이 빠르고, Windows 구독 갱신 오류 진단 글의 단계를 그대로 이어 붙이면 원인 분기가 줄어듭니다. 여러 구독을 합치거나 덮어쓰기를 쓰는 경우에는 멀티 구독·override 안내처럼 병합 순서를 정리해 두는 것이 혼선을 막습니다.

처음 설정이라도 속도 측정이나 간단한 사이트 열기를 한 번 해 두면 이후 트러블슈팅이 쉬워집니다. 코어가 안 떴을 때와 노드 품질 문제는 증상이 비슷해 보이기 때문에, 로그 패널을 켠 채로 같은 동작을 한 번 더 해보면 금방 갈라집니다.

4. 시스템 프록시: 브라우저가 따라오는 이유와 한계

시스템 프록시를 켜면 FlClash가 Windows의 수동 프록시 설정에 127.0.0.1과 같은 주소와 mixed-port에 해당하는 포트 번호를 채워 둡니다. Edge·대부분의 데스크톱 브라우저·사무용 앱은 이 값을 존중하므로, 코어와 노드만 정상이면 페이지가 곧바로 열립니다. 반대로 토글만 켜 두고 실제 Windows 설정에 숫자가 안 들어갔다면 다른 VPN 클라이언트나 정책이 덮어쓴 경우를 의심해야 합니다.

한계도 분명합니다. PowerShell이나 npm, 일부 게임·자체 소켓을 쓰는 도구는 OS 프록시를 보지 않고 직통으로 나갑니다. 사용자 커뮤니티에서 반복되는 「브라우저만 되고 터미널만 안 된다」 류 질문이 바로 이 경계에서 생깁니다. 이런 워크로드까지 한 번에 잡으려면 나중에 TUN이나 HTTP_PROXY 같은 환경 변수를 추가로 다뤄야 합니다.

5. 브라우저와 Windows 설정으로 검증하기

FlClash에서 코어를 띄운 뒤 시스템 프록시 스위치를 켭니다. 이어서 Windows 설정 > 네트워크 및 인터넷 > 프록시로 들어가 수동 프록시에 주소와 포트가 채워졌는지 확인합니다. 값이 비어 있거나 이상한 원격 주소를 가리키면 다른 소프트웨어가 간섭 중인 경우가 많습니다. 브라우저 쪽에서는 새 시크릿 창을 열어 IP 확인 사이트나 지연 테스트 페이지를 한 번씩 열어 기대한 지역·노드가 보이는지 봅니다.

크롬 사용자 중 시스템 프록시를 끄는 확장 프로그램을 쓰는 경우도 있으니, 증상이 브라우저 한 곳에만 갇혀 있으면 확장·실험적 플래그부터 끕니다. DNS 오버 HTTPS를 브라우저에만 강제해 두었다면 코어의 fake-ip·규칙과 엇갈려 보일 수 있어, Chrome·Edge 보안 DNS와 시스템 프록시 글을 같이 읽으면 정리가 빨라집니다.

# Sample: quick probe in PowerShell (may bypass system proxy)
curl.exe -sI --connect-timeout 8 https://www.cloudflare.com | Select-Object -First 3

위 명령은 기본적으로 시스템 프록시를 타지 않을 수 있으니, 브라우저와 결과가 다르면 「OS 프록시 미준수」 쪽에서 원인을 먼저 보는 근거가 됩니다. 반대로 TUN까지 켠 뒤에는 터미널 결과도 같이 변하는지 비교해 볼 수 있습니다.

6. 터미널·UWP·다음 단계(TUN)

명령행 도구를 매일 쓴다면 HTTPS_PROXY와 HTTP_PROXY를 사용자 프로필이나 셸 시작 스크립트에 넣는 식으로 범위를 정하는 편이 관리가 쉽습니다. Git과 GitHub CLI처럼 별도 설정 키가 있는 경우는 Git·HTTPS 프록시 글의 순서를 그대로 이어 붙입니다. Microsoft Store 앱(UWP)은 격리 정책 때문에 시스템 프록시만으로 부족할 때가 있어, 그때는 TUN·루프백 가이드를 참고합니다.

시스템 프록시로 대부분 앱을 검증한 뒤에도 전역 경로가 필요하면 FlClash에서 TUN 또는 동일 계열 스위치를 켭니다. 초회에는 Wintun 설치와 관리자 승인(UAC)을 요구하는데, 대화 상자를 닫고 빠져나오면 UI만 깜빡이고 기능은 적용되지 않은 채로 남는 경우가 많습니다. 상용 VPN이나 회사 보안 클라이언트와 동시에 전역 라우팅을 잡으려 하면 패킷이 두 겹으로 얽혀 증상이 난해해지므로, 테스트 구간에서는 한쪽만 켜 두는 습관이 진단 속도를 올립니다.

WSL2·Docker 데스크톱을 같이 쓰는 환경은 호스트에서 본 FlClash 상태와 리눅스 게스트의 기본 경로가 어긋날 수 있습니다. WSL2·mirror 네트워크 글을 곁에 두면 게스트 쪽 프록시 주소를 헷갈리지 않습니다.

7. 증상 나누기와 구독 오류

체크 순서는 간단히 네 덩어리로 나눌 수 있습니다. 첫째, 코어가 실제로 떠 있는지와 활성 프로필이 맞는지. 둘째, 구독 가져오기 갱신이 성공했는지와 노드 풀에 오류 표시가 없는지. 셋째, 시스템 프록시 토글과 Windows 설정의 수동 프록시 값이 일치하는지. 넷째, 다른 VPN·필터 드라이버·회사 패킷 검사가 끼어 있지 않은지입니다. 네 가지 중 하나만 깨져도 전체가 「안 된다»처럼 보이기 때문에 단계를 건너뛰지 않는 것이 중요합니다.

8. 자주 묻는 질문