Fedora에 Clash Meta 설치: systemd 부팅 자동 실행과 mixed-port 첫 설정 (2026)

1. Fedora에서 경로가 달라지는 이유

같은 Linux 데스크톱이라도 배포판마다 기본 방화벽, 보안 정책, 서비스 파일 위치가 조금씩 다릅니다. Fedora는 흔히 firewalld가 켜져 있고, 커뮤니티 패키지는 Copr이나 수동 설치로 들어오는 경우가 많습니다. 그래서 Ubuntu 글의 apt install ./패키지.deb를 그대로 가져오면 단계가 어긋납니다. 대신 dnf로 의존성을 맞추거나, 릴리스 아카이브에서 바이너리를 받아 /usr/local/bin에 두는 식으로 정리하는 편이 재현성이 높습니다.

Clash Meta는 기능 범위가 넓어 DNS·규칙·아웃바운드를 한 코어에서 다룹니다. Clash가 무엇인지 개념을 이미 알고 있다면, 이 글은 그 위에 Fedora 전용 운영 껍질(패키지·서비스·포트)을 씌우는 역할입니다. 코어가 뜬 뒤에는 라우팅·규칙 가이드에서 정책을 깊게 다루면 됩니다.

2. 사전 준비: 버전·SELinux·firewalld

rpm -E %fedora 또는 cat /etc/os-release로 릴리스 번호를 확인합니다. 오래된 바이너리는 glibc 요구가 맞지 않아 바로 실패하므로, 배포판 세대와 릴리스 노트를 함께 보는 습관이 필요합니다. SELinux는 Enforcing 상태에서 비정상 경로 실행이 막히는 경우가 있어, 서비스 사용자·실행 파일 위치·데이터 디렉터리를 일관되게 두는 것이 중요합니다. 문제가 생기면 ausearch·journalctl에 SELinux 관련 메시지가 붙는지 먼저 확인합니다.

firewalld가 활성화되어 있으면 로컬 루프백(127.0.0.1)은 보통 그대로 통과하지만, LAN 공유나 다른 기기에서 mixed-port 접속을 열 계획이라면 존(zone)과 서비스 허용을 별도로 설계해야 합니다. 이 글의 기본값은 본인 PC만 쓰는 로컬 바인딩입니다. sudo 권한이 있는 계정으로 진행하고, 코어는 가능하면 전용 시스템 사용자(예: mihomo)로 돌립니다.

3. 설치 경로: rpm·Copr·수동 바이너리

공식 리포지터리에 mihomo가 항상 들어 있는 것은 아니므로, 흔한 선택지는 다음과 같습니다. 첫째, 신뢰하는 Copr를 추가한 뒤 dnf install로 패키지를 받는 방법입니다. 저장소 이름과 패키지 이름은 시기마다 바뀌므로, 반드시 해당 Copr의 README를 따르고 여기서는 구체 이름을 고정하지 않습니다. 둘째, 프로젝트에서 배포하는 리눅스 바이너리를 내려받아 /usr/local/bin/mihomo에 두고 실행 비트를 주는 방법입니다. 셋째, 팀 내부에서 빌드한 rpm을 사내 리포지터리에 올려 dnf로 설치하는 엔터프라이즈 패턴입니다.

어떤 경로든 설치 후에는 command -v mihomo와 mihomo -v로 실행 파일 위치·버전을 확인합니다. 이름이 clash-meta인 빌드도 있으니 패키지 메타데이터를 함께 봅니다. 일반 사용자에게 권장하는 설치 패키지 경로는 이 사이트의 다운로드 페이지를 우선 참고하는 것이 일관됩니다. 오픈 소스 소스 코드·이슈·릴리스 노트는 상위 프로젝트의 GitHub에서 확인할 수 있으나, 브라우저에서 바로 받는 설치 안내의 1차 링크는 다운로드 페이지와 분리해 두는 편이 혼선이 적습니다.

4. 설정 디렉터리와 최소 config.yaml

서비스 형태로 돌릴 때는 /etc/mihomo처럼 시스템 경로에 두고, 개인 사용자 테스트는 ~/.config/mihomo에 둘 수 있습니다. 디렉터리 소유자는 systemd의 User=와 반드시 일치해야 하며, 여기에 config.yaml과 캐시·데이터베이스 파일이 생깁니다. 구독 가져오기 절차를 이미 알고 있다면 동일한 URL을 이 파일에 넣으면 됩니다.

최소 구성에서는 포트와 모드만 먼저 확정하는 것이 좋습니다. 아래는 개념 예시이며, 실제 키 이름·들여쓰기는 사용 중인 메이저 버전 문서를 따릅니다. 코멘트는 영어로만 적습니다.

# Minimal sketch — align keys with your mihomo release notes
mixed-port: 7890
bind-address: '127.0.0.1'
mode: rule
log-level: info
external-controller: '127.0.0.1:9090'
# ... proxies, proxy-groups, rules, dns ...

bind-address를 127.0.0.1로 두면 같은 PC의 앱만 붙고, LAN에서 쓰려면 의도적으로 범위를 넓히고 allow-lan 같은 옵션과 방화벽 규칙을 함께 설계합니다. 잘못 열면 외부 컨트롤러가 노출되므로 비밀번호·ACL을 기본값으로 두지 않는지 점검합니다.

5. mixed-port로 HTTP·SOCKS를 한 포트에

mixed-port는 HTTP 프록시와 SOCKS가 같은 포트에서 함께 동작하도록 정리해 주는 축입니다. 브라우저·IDE·패키지 매니저가 각각 다른 스킴을 요구해도, 데스크톱 쪽에서는 127.0.0.1:7890 한 줄만 맞춰 두고 앱마다 HTTP 또는 SOCKS를 고르면 됩니다. 터미널에서는 export http_proxy=http://127.0.0.1:7890, export https_proxy=http://127.0.0.1:7890, export all_proxy=socks5://127.0.0.1:7890처럼 환경 변수를 프로필에 넣고, 국내 레지스트리·사내망은 no_proxy로 빼는 패턴이 흔합니다.

external-controller는 웹 UI·REST 도구가 붙는 관리 포트입니다. 처음에는 루프백에만 바인딩해 두고, 외부망에 노출할 이유가 없다면 그대로 유지하는 것이 안전합니다. 포트 번호는 mixed-port와 겹치지 않게 잡습니다. 설정을 고칠 때마다 YAML 오류가 없는지 포그라운드 실행으로 한 번 검증한 뒤 systemd에 넣으면 재시작 루프를 줄일 수 있습니다.

규칙 모드에서 아직 규칙이 단순하면 예상과 다른 출구로 나가는 일이 있습니다. 이 단계에서는 우선 리스닝·로컬 curl까지만 맞추고, 트래픽 분기는 다음 섹션 이후에 다루는 편이 디버깅이 쉽습니다. Windows용 GUI 클라이언트와 달리, 코어 단독은 로그 한 줄이 곧 UI 역할을 합니다.

6. 수동 기동으로 리스닝·curl 검증

systemd에 넣기 전에 터미널에서 sudo -u mihomo /usr/local/bin/mihomo -d /etc/mihomo 형태로 띄워 봅니다. 경로는 환경에 맞게 바꿉니다. 다른 터미널에서 ss -lntp로 7890·9090이 열렸는지 확인하고, curl -I --proxy http://127.0.0.1:7890 https://www.example.com로 응답 코드를 확인합니다. 실패 메시지가 YAML 파싱이면 들여쓰기와 탭 혼용을 고치고, 권한이면 디렉터리 소유자와 DAC을 맞춥니다.

TUN 모드나 특정 capability가 필요한 빌드라면 수동 실행에서도 같은 오류가 재현됩니다. 이 경우 배포 문서의 setcap·별도 유닛 옵션을 따릅니다. 데스크톱에서 시스템 프록시만 쓸 계획이라면 TUN 없이 mixed-port만으로도 많은 앱을 커버할 수 있습니다.

7. systemd 유닛 작성

아래는 예시입니다. User·Group·ExecStart·WorkingDirectory는 환경에 맞게 바꿉니다. 파일은 /etc/systemd/system/mihomo.service에 둡니다.

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo (Clash Meta) on Fedora
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

Restart=always는 설정 오류가 있을 때도 무한 재시작될 수 있어, 초기에는 on-failure가 무난 편입니다. 여러 인스턴스를 띄울 때는 유닛 이름과 포트·디렉터리를 분리합니다. Fedora의 기본 타깃 체인은 대부분의 경우 multi-user.target에서 충분합니다.

8. enable·부팅 자동 시작·재시작 정책

유닛을 저장한 뒤 sudo systemctl daemon-reload를 실행하고, sudo systemctl enable --now mihomo.service로 지금 시작 + 부팅 시 자동 실행을 동시에 걸 수 있습니다. 상태는 systemctl status mihomo.service로 확인하고, 재부팅 후에도 active (running)인지 한 번 더 봅니다. DNS가 늦게 올라오는 환경에서는 첫 기동이 실패했다가 재시작으로 복구되는 패턴이 나올 수 있으므로, RestartSec을 지나치게 길게 두지 않는 실무 타협도 있습니다.

설정을 고친 뒤에는 sudo systemctl restart mihomo.service로 반영합니다. 바이너리만 교체했다면 동일합니다. 장애가 반복될 때는 코어 문제인지 노드 문제인지 분리하기 위해, 우선 journalctl 한 화면으로 범주를 나눕니다.

9. firewalld·journalctl·흔한 오류

로컬 루프백만 쓰면 방화벽 이슈는 적지만, LAN에서 접속하려면 firewall-cmd로 존에 포트를 열거나 풀(service) 단위로 허용해야 합니다. 운영 규칙은 조직마다 다르므로 여기서는 구체 명령을 강제하지 않고, 필요 최소 포트만 연다는 원칙만 강조합니다. 로그는 journalctl -u mihomo.service -e로 따라가면 되고, 실시간은 -f를 붙입니다.

흔한 원인은 설정 경로 오타, 디렉터리 DAC, 포트 충돌, DNS 루프입니다. ss -lntp로 PID를 찾아 충돌 상대를 밝히고, SELinux 거부가 보이면 컨텍스트·boolean을 문서대로 조정합니다. 루트로 코어를 돌리면 편해 보일 수 있지만 유출 시 위험이 커지므로, 가능하면 전용 사용자를 유지합니다.

10. GNOME·KDE 데스크톱 프록시 연결

GNOME 설정의 네트워크 프록시에 127.0.0.1과 mixed-port 번호를 넣거나, 수동·PAC 방식을 선택합니다. KDE도 유사하게 시스템 설정에서 HTTP·SOCKS를 지정할 수 있습니다. 일부 앱은 데스크톱 전역 설정을 따르지 않으므로, 그럴 때는 앱 내부 프록시 또는 환경 변수를 추가로 맞춥니다. Flatpak 앱은 샌드박스 때문에 별도 동작을 하는 경우가 있어, 문제가 생기면 해당 런타임 문서를 함께 봅니다.

터미널 세션 한정으로만 프록시를 쓰고 싶다면 셸 프로필 대신 env로 일회성 변수를 주입하는 방법도 있습니다. 서버에서 특정 데몬만 프록시를 타게 하려면 해당 서비스 유닛에 Environment=를 넣는 편이 깔끔합니다. 이 구성은 코어 기동·포트·systemd까지를 범위로 하고, 세밀한 도메인 분기는 규칙 파일에서 이어가면 됩니다.

11. 규칙·DNS는 다음 단계로

mixed-port와 systemd가 안정되면, 이후 병목은 대개 DNS와 정책 그룹 쪽으로 이동합니다. 스트리밍·협업 SaaS·개발 도구별로 도메인 묶음이 달라지므로, 한 번에 완벽한 규칙을 만들려 하기보다 로그를 보며 조금씩 확장하는 편이 운영 부담이 적습니다. 업데이트는 패키지 매니저 경로가 있으면 dnf upgrade로, 수동 바이너리면 교체 후 systemctl restart만 수행하면 됩니다.

마지막으로, 자동 기동은 가용성을 높이지만 잘못된 설정을 숨기지는 않습니다. 반복 장애가 있으면 journalctl과 코어 로그를 먼저 확보하고, 노드·DNS·규칙 순으로 좁힙니다. 이렇게 정리해 두면 Fedora·Clash Meta·systemd·mixed-port 조합이 재현 가능한 운영 절차로 남습니다.