Chromebook Linux(Crostini)에 Clash 설치: 구독 가져오기와 시스템 프록시·환경 변수 정렬(2026)

① Crostini를 알아야 「설치했는데 안 된다」가 풀립니다

Chromebook에서 말하는 Linux는 Windows의 WSL처럼, 가벼운 가상화 위에 올라간 사용자 공간입니다. 네트워크 스택도 크롬OS 호스트와 완전히 동일하지 않고, 컨테이너 내부의 127.0.0.1은 호스트의 127.0.0.1과 다르게 동작하는 경우가 있습니다. 그래서 다른 PC에서 익숙한 「시스템 프록시만 켜면 크롬까지 다 된다」는 그림을 그대로 기대하면 실망하기 쉽습니다.

핵심만 말하면, 크롬OS 기본 Chrome 브라우저는 Linux 컨테이너 안에서 돌아가는 Clash의 로컬 프록시를 자동으로 쓰지 않는 것이 보통입니다. 반대로 Linux 터미널에서 curl·git·apt는 환경 변수나 별도 설정이 없으면 컨테이너 밖으로 그대로 나갑니다. 「부분만 된다」는 체감은 이 경계에서 옵니다.

② 시작 전 체크: Linux(베타) 활성화와 디스크

설정에서 개발자용 Linux 개발 환경을 켠 뒤, 터미널이 열리면 컨테이너가 준비된 것입니다. 처음에는 sudo apt update로 인덱스를 갱신하고, 가능하면 시스템 업데이트까지 해 두면 코어 바이너리·GUI 의존성 설치 시 충돌이 줄어듭니다.

할당 용량이 빠듯하면 대용량 규칙 세트·로그가 쌓일 때 문제가 되므로, 정기적으로 캐시와 오래된 프로필 백업을 정리하는 습관이 좋습니다. 이 단계는 일반 데비안 노트북과 같다고 보면 되고, Ubuntu에서 Clash Verge·systemd 글의 「패키지·서비스」 감각과도 겹칩니다. 다만 크롬북에서는 커널 기능·권한이 제한되는 경우가 있어 TUN은 뒤 절에서 따로 짚습니다.

③ 어떤 빌드를 쓸까: 코어·GUI·권한

실무에서는 Meta(Mihomo) 기반 코어를 넣은 Linux용 클라이언트를 고르는 경우가 많습니다. 메뉴 이름은 제품마다 다르지만 흐름은 프로필 추가 → 구독으로 노드 갱신 → 로컬 포트에서 HTTP(S)·SOCKS 수신 → 규칙 적용으로 같습니다. 그룹과 규칙 문법이 헷갈리면 프록시 그룹(proxy-groups) 가이드를 먼저 훑는 편이 빠릅니다.

설치 패키지는 사이트 다운로드 페이지에서 현재 쓰는 플랫폼에 맞는 것을 고르고, 오픈소스 저장소는 소스·이슈 확인용으로 두는 편이 혼선이 적습니다. 프로젝트 정책상 클라이언트 설치 안내는 릴리스만 쫓기보다 입문 흐름과 함께 보는 것이 안전합니다.

④ 구독(Subscription) URL 넣고 프로필 갱신하기

프로필 화면에서 URL 가져오기 또는 새 구독을 선택하고, 공급자가 준 구독 주소를 붙여 넣습니다. 복사할 때 줄 앞뒤에 공백·줄바꿈이 끼면 실패하는 일이 많으니 메모장에 한 번 넣어 정리한 뒤 재복사하세요.

갱신이 비거나 403·429가 나면 만료·요청 제한·User-Agent 요구 등을 의심합니다. 원인별 정리는 구독 링크 FAQ에 모아 두었습니다. 여러 프로필이 있을 때는 활성 프로필이 맞는지 꼭 확인하세요.

⑤ 로컬 포트 맞추기: mixed-port vs 별도 포트

프로필의 mixed-port 또는 port·socks-port가 실제로 열려 있는지부터 봅니다. 예를 들어 HTTP·SOCSK을 한 포트에서 받는 설정이라면 클라이언트 대시보드에 표시된 숫자가 기준입니다. 터미널에서 ss -tlnp 같은 명령으로 리슨 여부를 확인할 수 있으면 더 좋습니다.

포트 번호가 정해지면 그다음 단계는 「그 숫자를 어디에 넣을지」입니다. 터미널 전역에는 아래와 같은 환경 변수가 표준입니다.

# Example — replace PORT with your Mixed/HTTP port from the Clash dashboard
export http_proxy="http://127.0.0.1:PORT"
export https_proxy="http://127.0.0.1:PORT"
export ALL_PROXY="socks5://127.0.0.1:PORT"
export NO_PROXY="localhost,127.0.0.1,::1"

ALL_PROXY를 SOCKS로 줄지, HTTP만 쓸지는 클라이언트가 연 포트 종류에 맞춥니다. NO_PROXY에 로컬 대역을 넣어 두면 내부 서비스 호출이 불필요하게 프록시를 타는 일을 줄일 수 있습니다.

⑥ 영구 적용: ~/.bashrc 또는 ~/.profile

위 export를 세션마다 치기 번거롭다면, ~/.bashrc 끝에 넣고 source ~/.bashrc로 반영합니다. 로그인 셸만 읽는 환경이라면 ~/.profile이 더 맞을 수 있습니다. 터미널 에뮬레이터가 어떤 셸을 쓰는지에 따라 파일이 갈리므로, 새 터미널을 열어 echo $http_proxy로 출력이 나오는지 확인하세요.

도구마다 프록시 환경 변수를 무시하는 경우도 있어, git은 git config --global http.proxy, npm은 npm config set proxy처럼 별도 키가 필요할 때가 있습니다. Windows와 WSL 사이의 호스트 주소·루프백 문제는 WSL2·Git·npm 글에서 다룬 것과 맥락이 비슷하지만, Crostini는 이번 글의 초점이 컨테이너 내부 일원화라는 점이 다릅니다.

⑦ 「시스템 프록시」와 Linux GUI 클라이언트 버튼

많은 데스크톱 클라이언트에는 시스템 프록시로 설정 같은 토글이 있습니다. 이것은 보통 해당 데스크톱 세션의 프록시 스킴을 건드리려는 기능이라, GTK/Qt 앱이 어떤 백엔드를 쓰느냐에 따라 결과가 갈립니다. 크롬OS Linux 안에서 이 토글을 켰다고 해서 호스트의 Chrome까지 연동된다고 보기는 어렵습니다.

그래서 「시스템 프록시를 켰는데 크롬이 안 바뀐다」는 것은 오히려 정상에 가까운 현상일 수 있습니다. 대신 Linux 쪽에 깐 Firefox·Chromium 등은 프록시 설정을 잡거나, 클라이언트가 제공하는 로컬 PAC/수동 프록시를 따라갈 여지가 있습니다.

⑧ 호스트 Chrome vs Linux 브라우저: 기대치를 나누기

매일 쓰는 창이 크롬OS 기본 Chrome이라면, Crostini 안의 Clash는 그 연결을 자동으로 가로채지 못하는 경우가 대부분입니다. 선택지는 크게 세 가지입니다. (1) Linux용 브라우저로 우회하려는 사이트를 연다. (2) 정책적으로 허용된다면 브라우저 실행 인자나 확장으로 프록시를 지정한다—다만 보안·관리 측면에서 환경마다 다릅니다. (3) 아예 라우터나 다른 기기에서 분기하는 구조로 설계를 바꾼다.

이 구분을 하지 않으면 「Clash는 켜졌는데 유튜브만 계속 예전 경로」 같은 혼란이 생깁니다. 반대로 Linux 터미널에서만 우회하면 된다면 환경 변수와 CLI 옵션만 맞춰도 목표는 달성됩니다.

⑨ TUN 모드: 크롬북에선 신중하게

TUN은 트래픽을 넓게 가져와 규칙을 적용하기 좋지만, 가상 인터페이스·라우팅이 필요하고 권한 요구가 큽니다. Crostini는 배포판·크롬OS 버전에 따라 허용 범위가 달라, 같은 YAML이라도 데스크톱 Linux에서 되던 것이 컨테이너에선 안 되거나, 다른 VPN·서비스와 충돌할 수 있습니다. 원리와 체크 순서는 TUN 모드 심화 글을 참고하고, 여기서는 「안 되면 HTTP/SOCKS + 규칙으로 범위를 줄여 가동증명부터」가 현실적인 순서입니다.

⑩ DNS·fake-ip: 터미널과 규칙이 따로 노는 증상

프로필에 fake-ip나 DoH가 있으면, 이름 해석 경로가 기대와 다르게 보일 수 있습니다. 브라우저 DNS만 켠 상태에서 코어 DNS와 이중으로 쓰면 규칙이 꼬이기도 합니다. 이때는 한 번에 한 계층만 바꾸며 연결 로그로 목적지와 적중 규칙을 적는 방식이 안전합니다. 세부 튜닝은 사용자 정의 규칙 흐름과 같습니다.

⑪ 자동 실행: systemd 사용자 유닛 또는 시작 스크립트

크롬OS·Crostini 조합에 따라 systemd --user가 동작하는 경우가 있습니다. 동작한다면 코어 실행 파일과 프로필 경로를 인자로 주는 .service를 만들어 활성화할 수 있습니다. 반대로 제한이 크면 로그인 후 수동 실행이나 간단한 셸 스크립트를 쓰게 됩니다. 핵심은 재부팅 뒤에도 같은 포트가 다시 열리게 만드는 것이고, 그래야 http_proxy도 매번 같은 값을 가리킵니다.

⑫ 문제 해결: 증상별로 좁히기

1. 코어가 안 뜬다: 바이너리 권한·의존성·프로필 경로 오류를 먼저 본다.
2. 터미널만 안 탄다: echo $https_proxy, curl -v로 환경 변수 적용 여부를 확인한다.
3. 호스트 Chrome만 안 탄다: ⑧절의 경계 문제인지 확인하고, Linux 브라우저로 재현해 본다.
4. 노드는 있는데 특정 사이트만 실패: 규칙 순서·MATCH·DNS를 로그로 적는다.
5. TUN만 실패: 권한·커널·다른 VPN 충돌을 의심하고 HTTP/SOCKS 모드와 비교한다.

⑬ 정리

Chromebook의 Crostini는 훌륭한 Linux 실습 공간이지만, 프록시를 올릴 때는 어디까지가 같은 상자 안인지를 먼저 그려야 합니다. 구독 가져오기와 로컬 포트는 맞는데도 체감이 어긋나면, 환경 변수와 브라우저가 실행되는 층을 나눠 점검하세요. 그 다음에야 시스템 프록시 버튼이나 TUN 같은 상위 모드를 확장하는 편이 시간 낭비가 적습니다.

클라이언트 종류와 설정 흐름을 한번에 잡고 싶다면 Clash 입문 튜토리얼을 함께 보고, 장기 유지·분기 이유를 비교하고 싶다면 Clash와 VPN의 차이도 참고하면 선택 기준이 선명해집니다.

규칙 기반으로 트래픽을 나누는 도구 특성상, 한 번 프로필 구조를 잡아 두면 다른 기기로 옮겨도 같은 정책을 재사용하기 쉽습니다. 설치 파일 혼선을 줄이려면 사이트에서 안내하는 경로를 따라가는 편이 낫습니다. → Clash를 무료로 내려받고, Chromebook Linux에서 구독·프록시·환경 변수를 한 줄에 맞춰 보세요.