Fedora Workstation에서 Clash Verge 첫 설치: SELinux와 firewalld를 맞추는 분기별 점검(2026)

① 왜 Fedora에서는 Ubuntu 때와 증상이 다른가요?

2026년 기준으로도 Linux 데스크톱 검색은 배포판 이름과 함께 묶입니다. Fedora Workstation은 최신 커널·툴체인을 빠르게 받는 대신, 기본 보안 프로파일이 보수적인 편입니다. SELinux는 프로세스·파일·포트에 보안 컨텍스트를 붙여 “이 바이너리가 이 소켓을 열어도 되는가”를 커널 수준에서 판단하고, firewalld는 존(zone)과 서비스·포트 단위로 인바운드를 정리합니다. 반면 많은 Ubuntu 설치본은 AppArmor와 UFW 조합이 기본이라, 거절 메시지의 모양이 다릅니다.

Clash Verge는 GUI로 프로필을 고르고 코어를 띄우는 클라이언트이므로, “설정 파일은 맞는데 실행 단계에서 막힌다”면 OS 보안 스택을 의심하는 것이 빠릅니다. 전체 그림은 2026년 Clash 생태계 글에서 한 번 잡아 두면, 코어 이름과 클라이언트 빌드 차이를 정리하기 쉽습니다.

② 설치 전에 고정할 것: 패키지 형태·경로·권한 모델

Fedora에서 서드파티 GUI는 RPM, Flatpak, 혹은 배포자가 안내하는 AppImage·압축 바이너리 형태로 제공되는 경우가 많습니다. 어떤 형식이든 공통으로 확인할 것은 실행 파일의 실제 경로와 홈 디렉터리 아래 설정 폴더입니다. 이후 systemd 사용자 서비스를 쓸 때 ExecStart=에 그대로 들어가므로, 설치 직후 which나 앱 정보 화면에서 경로를 메모해 두면 재작업이 줄어듭니다.

오픈소스 GitHub 저장소는 라이선스·이슈 확인용으로 두고, 설치 패키지를 받는 주 경로는 사이트 안내를 따르는 편이 버전 혼선이 적습니다. 같은 맥락에서 클라이언트를 한곳에서 내려받아 두면 재설치 후에도 경로를 잃어버리지 않습니다.

③ Clash Verge 설치와 구독(Subscription) 가져오기 — 공통 흐름

빌드마다 메뉴 이름이 조금 다르지만 큰 줄기는 같습니다. 앱을 한 번 실행해 셸이 뜨는지, 트레이 아이콘·백그라운드 동작 정책이 GNOME 설정과 맞는지 확인합니다. 그다음 프로필 화면에서 구독 URL을 넣고 갱신합니다. 복사 과정에서 앞뒤 공백이 섞이면 실패하는 경우가 많으니, 메모장에 한 번 붙여 넣어 정리한 뒤 다시 복사하는 습관이 좋습니다.

갱신이 안 되거나 목록이 비면 만료·레이트 리밋·User-Agent 요구 등을 의심합니다. 이런 증상은 OS를 가리지 않으므로 구독 링크 FAQ를 함께 보면 원인 분기가 빨라집니다. 여기까지는 Ubuntu 글과 동일한 “앱 내부” 이야기이고, Fedora에서 막히는 지점은 이후 SELinux·firewalld 쪽으로 자주 넘어갑니다.

④ SELinux가 의심될 때: 거부 로그를 먼저 본다

SELinux가 Enforcing이면 “조용히 실패”하기보다 감사 로그에 흔적이 남는 경우가 많습니다. 터미널에서 sudo ausearch -m avc -ts recent처럼 최근 AVC 거부를 조회하거나, sudo journalctl -xe | grep denied로 메시지를 훑어 봅니다. GUI 환경에서는 setroubleshoot 계열 도구가 있으면 팝업으로 요약을 주기도 합니다.

로그에 클라이언트 바이너리나 코어 프로세스 이름이 찍히면, 그때는 “이 실행 파일이 기대한 도메인이 아니다”, “포트 레이블과 맞지 않다” 같은 이유로 거절된 것입니다. 이때 무작정 Permissive로 전환하기보다, 임시로 Permissive에서 재현 후 로그를 확보하고 다시 Enforcing으로 돌아오는 절차가 안전합니다. 영구적으로 넓히는 경우에도 특정 바이너리·포트에 한정된 정책을 쓰는 편이 좋습니다.

# Recent AVC denials (example)
sudo ausearch -m avc -ts recent

# If setroubleshoot is installed, alerts may also appear in the journal
sudo journalctl -u setroubleshootd -e

배포판 업데이트로 바이너리가 바뀌면 파일 컨텍스트가 어긋날 수 있습니다. 패키지 관리자로 설치한 파일이라면 sudo restorecon -RFv /path/to/binary 같은 라벨 복구가 도움이 되는 경우도 있습니다. 다만 사용자 홈 아래에 풀어 쓴 AppImage는 경로마다 라벨 규칙이 달라질 수 있어, 고정 디렉터리에 두고 경로를 바꾸지 않는 운영이 덜 고생입니다.

⑤ firewalld: 언제 건드려야 하나요?

많은 사용자 환경에서 로컬 루프백(127.0.0.1)으로만 뜨는 프록시 포트는 firewalld 바깥에서 처리되거나, 기본 정책에 걸리지 않는 경우가 많습니다. 그럼에도 증상이 “같은 Wi‑Fi의 휴대폰에 Allow LAN으로 공유하려는데만 안 붙는다”라면 인바운드를 의심합니다. Clash Verge에서 LAN 허용을 켜면 데몬이 0.0.0.0이나 LAN IP에 바인딩하고, 이때 firewalld의 public 존에서 해당 TCP 포트가 막혀 있을 수 있습니다.

먼저 sudo firewall-cmd --state로 동작 여부를 확인하고, 어떤 존이 활성인지 sudo firewall-cmd --get-active-zones로 봅니다. 필요한 경우에만 특정 포트를 열고, 범위를 넓히지 않는 편이 좋습니다. 예시는 환경마다 포트 번호가 다르므로, 앱에 표시된 mixed-port·HTTP/SOCKS 포트에 맞춰 바꿉니다.

# Show firewalld status and active zones
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones

# Example: open a TCP port in the default zone (replace 7890 with your port)
sudo firewall-cmd --permanent --add-port=7890/tcp
sudo firewall-cmd --reload

집·사무실 네트워크 정책이 다르므로, 공용 Wi‑Fi에서는 LAN 공유 자체를 끄는 편이 안전합니다. Windows 쪽 같은 Wi‑Fi에서 PC 프록시 쓰기 시나리오는 Win11 LAN·방화벽 글과 대조하면 개념이 빨라집니다.

⑥ TUN 모드·권한: 커널 모듈과 capabilities

TUN을 켜면 가상 NIC 경로로 트래픽을 넓게 잡을 수 있지만, 권한과 다른 VPN·네트워크 스택과의 충돌을 함께 봐야 합니다. Fedora에서 클라이언트가 /dev/net/tun을 열지 못하거나 라우팅을 바꾸지 못하면, 앱 로그에 권한 오류가 남는 경우가 많습니다. 이때도 SELinux 거부가 동반되는지 앞 절의 로그를 다시 확인합니다.

원리·점검 순서를 더 깊게 보고 싶다면 TUN 모드 심화 글의 흐름을 참고하면 Linux에서도 진단이 수월합니다. 시스템 프록시만 쓸 때와 TUN을 켰을 때의 차이를 혼동하면 “일부 앱만 안 된다”는 증상이 반복됩니다.

⑦ systemd 사용자 유닛으로 로그인 후 자동 실행(선택)

그래픽 자동 시작(.desktop)이 가장 단순한 경우가 많고, systemd --user는 재시작 정책·로그를 명확히 남기고 싶을 때 유리합니다. Fedora에서도 ~/.config/systemd/user/ 아래 유닛을 두고 systemctl --user enable --now 서비스명으로 올립니다. 실패 시 journalctl --user -u 서비스명 -e로 “DISPLAY 없음”, “실행 파일 없음”을 빠르게 갈릅니다.

# Example user service paths on Fedora
mkdir -p ~/.config/systemd/user
# edit ~/.config/systemd/user/clash-verge.service  (ExecStart must match your binary)
systemctl --user daemon-reload
systemctl --user enable --now clash-verge.service

Wayland·X11 혼용 환경에서는 그래픽 세션 변수 전달 문제로 자동 시작만 실패하는 경우도 있어, 이때는 유닛의 After=·세션 타깃을 빌드 문서에 맞게 조정합니다.

⑧ 검증 순서: 포트·프로세스·프록시 적용을 한 줄씩

아래는 한 번에 여러 가설을 섞지 말고 위에서부터 밟는 순서입니다.

1. 클라이언트에서 코어 실행·시스템 프록시/TUN이 실제로 켜졌는지 확인합니다.
2. ss -lntp로 리슨 주소가 127.0.0.1인지, LAN으로 열렸는지 확인합니다.
3. 브라우저·터미널이 시스템 프록시를 따르는지, 예전 수동 프록시가 남아 있지 않은지 확인합니다.
4. SELinux 거부가 있었는지 AVC 로그를 다시 확인합니다.
5. firewalld를 켠 상태에서 LAN 인바운드가 필요한지, 필요하면 포트 예외만 최소로 추가합니다.
6. DNS가 꼬이면 “사이트만 안 열린다”로 보입니다. 프로필의 DNS·fake-ip를 함께 봅니다.

프록시 그룹 구조가 헷갈리면 프록시 그룹 가이드로 이름과 정책을 맞춥니다.

⑨ 정리: Fedora는 “앱 설정 + OS 보안 스택”을 한 세트로 본다

Fedora Workstation에서 Clash Verge를 처음 쓸 때의 핵심은, 구독만 넣었다고 끝이 아니라는 것입니다. Debian 계열 튜토리얼에서 잘 나오지 않던 SELinux·firewalld가 기본 켜짐 상태로 함께 있으므로, 증상이 네트워크 레이어에 가려 보일 수 있습니다. 로그로 원인을 가른 뒤 최소 권한으로만 완화하고, LAN 공유나 TUN처럼 범위가 넓어지는 기능은 정책·환경을 확인한 다음 켜는 편이 안전합니다.

상용 VPN 앱과 비교해 Clash 계열은 처음 설정이 길어 보일 수 있지만, 한 번 구조를 잡아 두면 구독과 규칙을 같은 방식으로 다른 기기에도 가져갈 수 있습니다. 처음 전체 흐름을 잡고 싶다면 Clash 입문 튜토리얼을 먼저 밟아 두면 이후 점검 순서가 훨씬 단순해집니다. 설치 패키지는 릴리스만 쫓기보다 사이트의 다운로드 페이지를 기준으로 두는 편이 혼선이 적습니다. → Clash를 무료로 내려받고, Fedora에서도 규칙 기반 프록시를 안정적으로 써 보세요.