CentOS Stream 9·RHEL 9 서버에 Mihomo(Clash Meta) 바이너리로 올리기: 경로 정리·구독·systemd 부팅 자동 시작

① 검색 결과가 우분투뿐일 때 왜 따로 분리해야 할까?

RHEL 9 계열은 패키지 체인과 SELinux 적용 기본값·firewalld 존재감 때문에 그냥 bash 스크립트만 복사해 오면 즉석에서 막히는 지점이 DEB 기반 안내문과 다릅니다. CentOS Stream 9는 속도 빠르게 따라가며 개발 초점과 협착 테스트가 교차해서, 회사에서는 “스트림 테스트베드 + 상용 계약 RHEL” 조합까지도 흔합니다. 운영팀 검색에는 CentOS Stream 9 Mihomo 설치, RHEL 9 Clash Meta, 헤드리스 리눅스 systemd 프록시처럼 배포판 이름을 붙인 구문이 많이 들어오는데, 해당 키워드가 들어 간 글이 있어야 시간을 아낍니다.

Mihomo 계열 코어가 주는 장점은 표준 규칙 표현과 원격 패키지, DNS·스니핑 레이어를 한 파일 근처에서 다룰 수 있다는 점이라, 레거시 프록시 데몬만 올린 경험이 있어도 config.yaml 구조 숙련이 함께 필요합니다. 전체 이름 정리와 포크 차이 맥락은 2026년 Clash 생태계 한 편과 맞춰 보시면 Mihomo 안에서 어떤 키가 최신 재작성 대상인지 직관이 잡힙니다.

② 사전 확인: 버전 문자열·커널·아키텍처부터

터미널에서 어떤 9 버전 줄기에서 돌아가는지·CPU가 무엇인지부터 고정해야 자산 이름을 틀리지 않습니다. cat /etc/os-release로 PLATFORM_ID나 NAME을 보고 워크스테이션용 RHEL 미니 설치본인지 클라우드 이미지인지 구분하면 이후 패치 주기까지 설계에 들어갑니다. 또 immutable에 가까운 특수 이미지라면 바이너리를 사용자 홈이 아니라 /opt 또는 /usr/local처럼 정책상 허용된 트리에 두는 규칙이 있으니 변경 관리 규칙서를 우선 확인하세요.

uname -m가 x86 계열인지 aarch64인지에 따라 받을 압축 파일 접미사가 바뀌고, 회사 레지스트리에 미러를 올린다면 해당 해시 검증 규격도 같은 표에 적어 두는 편이 감사에 유리합니다. 이미 회사 레드햇 EUS나 Extended Update Support 범위에 묶였다면 자동 업데이트 스크립트가 과도하게 옮기면 안 되므로 systemd 유닛 옆에 변경 차단 플래그를 문서화하는 게 좋습니다.

③ 바이너리 선택과 신뢰 경로 원칙

조직에서는 “다운로드한 단일 실행 파일”을 허용하는지부터 정책이 갈립니다. 허용된다면 소스 레포 또는 릴리스 페이지에서 표기된 체크섬을 반드시 맞추고, 버전 문자열 기록까지 감사 추적 가능하게 두세요. 패키지가 아니라 파일형 자산이므로 회사 레드햇 sandbox나 제한된 업로드 채널을 통과하는 절차를 선행해야 운영 권한이 줄어들지 않습니다.

설치 과정에서는 흔히 gzip 또는 xz로 압축된 단일 바이너리를 받은 뒤 mihomo처럼 짧은 이름으로 바꿔 둔다는 패턴입니다. 이름이 레포마다 미세하게 달라 마지막으로 직접 mihomo -v로 확인하는 버릇이 안전합니다. 의료·금융 망이라면 회사 제공 GPG 검증 플레이북에 맞춰 서명 문자열 순서까지 맞춰야 하는데, 방법은 장표마다 조금 다르므로 규정팀 초안과 정합부터 맞추는 일이 필요합니다.

④ 디렉터리 레이아웃 권장: 실행 파일과 설정 분리

운영에서는 실행 파일(읽기 전용)·런타임 상태·구성 원본을 헷갈리지 않게 두는 방법이 업그레이드 비용을 낮춥니다. 예시로 실행 파일은 /usr/local/bin/mihomo, 구성 디렉터리는 /etc/mihomo 아래에서 메인 설정과 provider 캐시, 가끔은 geo 데이터 자리만 나눠도 업무 인수인계 속도가 달라집니다.

별도 계정을 쓰고 싶다면 전용 사용자(예시 이름 mihomo)를 만들어 홈 디렉터리는 비우고 서비스가 읽어야 하는 트리에만 접근 가능하게 하는 편이 /root 직행보다 회사 레드햇 규격에 거슬리지 않습니다. 셸까지 열 필요가 없도록 nologin 셸 속성까지 맞춰 두세요. 상태 파일 디렉터리는 런타임에 만들어져야 하는 경우가 많으므로 서비스 본체가 작성할 디렉터리에 적절한 소유 주체를 한 번 확인합니다.

⑤ 최소 동작 가능한 설정 골격과 구독 URL을 proxy-providers에

운영 테스트 단계에서는 먼저 짧은 패킷 교환까지 되는 라인업을 목표로 잡습니다. http(s)/socks/mixin 포트 줄기 같은 키는 릴리스 문서 버전별로 이름이 진화하므로, 실제 설치한 바이너리가 허용하는 키를 릴리스 노트와 mihomo -h로 확인할 수 있는 구성 검증·테스트 방법으로 서로 대조해야 합니다. 문법만 맞았다 해도 null DNS나 잘못된 기본 이름 서버 순서 때문에 겉보기엔 깨져 보이므로 회사 레드햇 내부 DNS 정책과 맞물리는 문제를 동시에 봅니다. stub resolver 교차 이슈는 Linux에서 systemd-resolved와 Clash 같은 글로 상위 패턴 비교 후 이 서버에서는 어떤 데몬이 사실 상위 리졸브인지만 정하면 됩니다.

구독은 자주 접하는 두 가지로 나뉩니다. 하나는 제공자 서버와 직결되는 원격 패키지 형태며, 다른 하나는 이미 사람이 작성한 규칙과 노드 이름이 포함된 패키지를 직렬화한 줄기입니다. Mihomo 류에서는 proxy-providers 줄기에 원격 리소스 URL을 넣고 경로·갱신 주기 같은 보조 속성까지 얹는 방식으로 자동 새로 고침이 동작하게 할 수 있습니다. 복사한 URL에 줄바꿈이 들어오면 깨져서 결과가 빈 줄로 보입니다. 문자열 깨짐 말고도 User-Agent 또는 Referer 고정 요구가 많으므로 해당 값이 패키지에 없다면 구독 FAQ에서 요청 속성 순서부터 맞춥니다.

⑥ systemd 예시 서비스: 부팅 이후 즉시 올림

시스템 유닛을 쓸 때에는 실행 시작 커맨드에 구성 디렉터리를 넘길 방법이 레포별로 차이 나므로, 공식 헬프를 찾았을 때 쓰이는 같은 플래그를 붙입니다. 많은 패턴에서는 설정 디렉터리를 인자 또는 환경으로 주고 장애 재시작을 on-failure처럼 짧게 잡거나 시간 제한 backoff를 넣는 편입니다. 유닛을 고칠 때마다 daemon-reload를 잊지 마세요.

# /etc/systemd/system/mihomo.service 예시 스켈레톤
[Unit]
Description=Mihomo (Clash Meta) proxy core
After=network-online.target

[Service]
User=mihomo
Group=mihomo
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

위 스켈레톤은 조직별로 수정해야 하는 부분이 많습니다. TUN이나 브리지 기능을 헤드리스에서 활성화하려면 네트워크 네임스페이스·라우팅 정책·NIC 우선 순위가 모두 새 제약이라 사내 테스트랩에서 레드햇 제공 가이드를 읽어 온 다음 한 단계만 붙입니다. 과도하게 늘리면 재부팅 시마다 loop에 빠져 운영 콜이 터집니다.

⑦ firewalld와 단일 게이트웨이처럼 받을 포트 허용

RHEL 패턴에서는 firewalld 존중이 업무 디폴트입니다. 동일 장비에서 회사 허브가 mihomo 로컬 SOCKS를 조회해야 한다면, 조직 정책에 맞춰 존 이름을 정해서만 열거나 아예 내부 전용 존 블록에 넣어둡니다. 외부로 그대로 드러나게 하면 회사 레드햇 보안 검토에서 바로 들어오니, 테스트 기간이라도 허용 IP 대역 줄기부터 문서에 붙입니다. 서비스로만 열려고 하면 존 속성 때문에 실제 체크리스트 순서와 다르게 먹통이 되는 예가 많아 재부팅 이후 존 상태를 자동 테스트하는 스모크까지 넣는 편을 권합니다.

⑧ SELinux: 실행 거부 같은 저항이 생기면 순서부터

헤드리스 RHEL류에서 가장 헷갈리는 레이어가 SELinux 차단 로그와 유닛 실패입니다. 새 경로 실행 파일이라면 레이블이 맞지 않아 시작만 반복히 실패하는 경우가 많고, 상태 파일 디렉터리에 쓸 권한이 없으면 초기 시작 직후 죽는 패턴도 나옵니다. 운영팀에서는 일시 허용 브로드를 남발하기보다, 감사에 남길 레이블·정확 차단 줄기 같은 승인 패치를 통해 조직 허브에 올린 뒤에만 허용하는 것이 회사 레드햇 실태에 맞습니다.

그래픽이 있는 다른 배포판에서 익숙하게 풀렸던 문제가 회사 레드햇 헤드리스에서는 막히는 이유 중 하나입니다. 패턴 교차 비교만 하고 싶다면 Fedora 데스크톱 레이어별 설명과 짝 지어져 있는 글 역시 같은 축이라 Fedora Verge SELinux 장을 같이 놓습니다.

⑨ 동작 검증과 로그·업데이트 운영

서비스를 올린 직후엔 표준 헬스 줄기 같은 것이 패키지에 있다면 간단 확인을 하지만, 헤드리스 환경은 주로 포트 상태와 패킷 흐름으로 판별합니다. journalctl -u mihomo -e로 반복 시작 루프가 없는지, 구독 패치가 시간마다 새로 들어 오는지, DNS 오류가 없는지를 보지 않으면 밤 새 운영 콜이 남습니다.

업그레이드는 바이너리 파일만 치환하는 경우가 많으니, 교체 순간에 구성 호환 줄기 깨졌을 때 즉석 롤백 디렉터리를 같은 트리에 두는 방식까지 문서 한 줄 채워 두면 교대 인계가 줄어듭니다. 테스트 기간이라도 허브가 기대할 수 있는 속도 패턴까지 정리해야 상용 SLA를 맞출 수 있습니다.

⑩ 헤드리스만의 한계 인지 후 그래픽 도구 선택

헤드리스 데몬만으로 회사 허브를 충족했다면 업무는 종료처럼 느껴질 수 있지만, 패키지 디버깅이나 패턴 탐색이 잦아지면 터미널 하나로 시간이 과소비됩니다. 운영팀 업무 패턴에는 GUI가 포함되기 때문에 데스크톱 쪽에서는 별도 채널로 도구 선택을 허브에 기록해야 합니다. 상위 패턴 교육까지 한 번 가져오려면 Clash 입문 튜토리얼에 손만 대도 용어 교정이 빨라집니다.

FAQ: 짧게 다시 확인

RHEL이라 apt 스크립트를 그대로 쓸 수 있나요?

대부분의 공개 스크립트는 우분투 줄기 패키지 경로와 의존성 이름을 전제합니다. 헤드리스 RHEL이라면 패키지나 컨테이너 패턴을 조직 허브에 맞춰 다시 작성하는 편이 안전합니다.

직접 데몬 대신 패키지로 싸서 배포해야 하나요?

회사 허브에 맞춰 회사 패키저가 있다면 해당 포맷이 정답이고요, 아니면 이번처럼 레드햇이 받아들일 수 있는 /usr/local 패턴을 문서로 한정하는 경우가 많습니다.

마무리: 왜 헤드리스에서도 레이블을 맞춰야 하는가

일부 전통형 프록시 데몬이나 망 종단 VPN 솔루션은 패널에서는 단순해 보여도 헤드리스에서 라우팅·DNS·예외 처리를 깊게 들어가면 줄마다 수동 패치해야 해서 교대 업무 시간이 새어 나갑니다. 반면 Clash 계열 코어처럼 규칙·구독·DNS를 같은 YAML 줄기 근처에 두면 변경 이력이 git 같은 도구와도 합류하기 쉬워 엔터프라이즈 점검이 수월합니다. 그래픽 검증이 필요할 때만 데스크톱 클라이언트를 허브에 맞춰 골라 쓰면 되고, 서버 헤드리스는 systemd와 로그로 일관 상태를 재현하면 됩니다. 설치 패키지와 버전 정보를 한곳에서 맞춰 보고 첫 테스트를 시작하려면 Clash 다운로드 페이지에서 받아 보세요. 교대 장표 작성 부담도 조금 줄어 듭니다.