iOS에서만 구독 가져오기가 꼬이는 이유

iPhone에서 Clash 구독을 넣는다는 것은, 앱이 지정한 구독 링크로 HTTPS 요청을 보내 응답 본문을 파싱하는 과정입니다. 데스크톱과 달리 iOS 앱은 백그라운드 제한·셀룰러 절전·VPN/프로파일과의 상호작용 때문에 「같은 URL인데도」 실패 메시지가 다르게 보일 수 있습니다. 특히 Stash는 Clash 설정 문법에 가깝게 다루고, Shadowrocket은 범용 프록시 클라이언트에 가깝기 때문에, 같은 「가져오기 실패」라도 원인 후보가 조금씩 갈립니다.

사용자가 자주 보는 증상은 세 가지 축으로 묶입니다. 첫째, 아예 원격에서 목록을 받아 오지 못해 다운로드 실패 또는 시간 초과가 뜨는 경우입니다. 둘째, 연결은 시도했지만 TLS 핸드셰이크에서 막혀 인증서 관련 문구가 나오는 경우입니다. 셋째, HTTP 상태는 성공인데 파싱 결과가 비어 노드 목록이 비어 있거나 예전 스냅샷만 남는 경우입니다. 이 세 축은 서로 다른 층(네트워크·암호화·본문 형식)이므로, 로그에 찍힌 키워드를 먼저 구분하는 것이 빠릅니다. 클라이언트 종류별 특징은 클라이언트 선택 가이드와 함께 보면 화면 위치를 덜 헷갈립니다.

⚠ 준수: 현지 법령·네트워크 이용 약관·고용주·학교의 정책을 준수하세요. 본문은 허용된 환경에서의 연결 진단을 돕기 위한 기술 설명이며, 무단 우회를 조장하지 않습니다.

앱을 열기 전에 확인할 공통 사항

앱 내부 설정을 뒤지기 전에, 아래는 모든 iOS 클라이언트에 공통으로 해당됩니다. 구독 링크를 복사할 때 줄 끝 공백·스마트 따옴표·메신저가 넣은 보이지 않는 문자가 섞이면 서버는 정상인데 앱만 실패하는 것처럼 보일 수 있습니다. 메모장이나 짧은 메모 앱에 한 번 붙여 넣었다가 다시 복사하면 이런 문자가 많이 걸러집니다.

다음으로 날짜·시간이 맞는지 확인하세요. iOS는 시스템 시각이 크게 틀어지면 TLS 인증서 유효 기간 검증이 실패해 「신뢰할 수 없음」류 메시지가 납니다. 여행·수동 설정·배터리 방전 직후에 특히 흔합니다. 저데이터 모드나 배경 앱 새로고침 제한이 켜져 있으면 구독 갱신 타이밍이 밀려 실패로 찍히기도 하니, 재현할 때는 한 번 끄고 비교해 보는 편이 좋습니다.

같은 Wi-Fi에서만 실패한다면 캡티브 포털(공항·카페 로그인)이나 DNS 가로채기가 의심됩니다. 셀룰러 데이터로 잠시 바꿔 같은 구독 링크를 가져와 보면, 망별로 갈리는지 빠르게 가릅니다. HTTP 403·404·User-Agent 차이는 데스크톱과 동일하게 나타나므로, 구독 갱신 404·403·UA 가이드의 순서를 iOS에 그대로 옮겨 적용할 수 있습니다.

ℹ 먼저 할 일: Safari에서 구독 URL을 열었을 때 본문이 YAML·Base64 형태로 보이는지, 아니면 HTML 로그인 페이지로 돌아가는지부터 확인하세요. 후자라면 앱 문제가 아니라 세션·만료·잘못된 링크 쪽이 우선입니다.

Stash: 구독 추가·TLS·로그에서 보는 패턴

Stash는 iOS에서 Clash 계열 설정을 비교적 그대로 다루는 편이라, 프로필·패키지·원격 구독이 한 흐름으로 묶입니다. 구독을 새로 넣을 때는 (1) 대시보드에서 받은 URL이 최신인지, (2) https:// 스킴이 맞는지, (3) 토큰이 포함된 긴 쿼리가 잘리지 않았는지를 우선 확인하세요. 이름만 바꾸고 URL 필드가 예전 값을 가리키는 실수는 초보든 숙련자든 자주 납니다.

TLS 오류가 날 때 Stash에서 보는 것

TLS 관련 문구가 뜨면, 먼저 그 링크가 공인 CA로 서명된 서버인지부터 봅니다. 일부 자체 호스팅 패널은 만료가 임박했거나 체인이 불완전한 인증서를 올려 두기도 합니다. iOS는 엄격한 편이라, 데스크톱 브라우저에서는 우회 옵션으로 열려도 앱 요청은 실패할 수 있습니다. 가능하면 제공자에게 체인 교체를 요청하는 것이 근본 해결입니다.

기업용 MDM 프로파일이나 보안 제품이 기기에 루트 인증서를 심어 두면, 사용자가 의식하지 못한 채 신뢰 저장소가 달라져 예상과 다른 TLS 검증 경로를 탈 수 있습니다. 이런 환경에서는 「집 Wi-Fi에서는 되고 회사망에서만 안 된다」 패턴이 나오기 쉽습니다. 개인 기기라면 설정 앱의 일반·VPN 및 기기 관리·프로파일 항목을 한 번 훑어 이질적인 프로파일이 있는지 확인하세요.

로그·갱신 UI로 좁히기

Stash는 구독 소스별로 갱신 시점과 결과를 보여 주는 경우가 많습니다. 실패 시 메시지에 timeout만 있는지, certificate·handshake 같은 단어가 있는지 구분하세요. 전자는 망 품질·DNS·방화벽 쪽, 후자는 인증서·시간·중간자 공격 탐지 쪽으로 의심 범위가 좁아집니다. 연결 계층 전반은 연결 로그·TLS 가이드와 연결해 읽으면 데스크톱과 같은 용어로 정리하기 쉽습니다.

로그에 자주 붙는 키워드(의미 파악용) 
TLS handshake failed / certificate verify failed
Get "https://...": context deadline exceeded

Shadowrocket: Clash 링크·오류 메시지 대응

Shadowrocket은 「Clash 구독」이라는 별도 유형으로 URL을 받아 노드를 채우는 흐름이 있습니다. 여기서 말하는 Clash는 데스크톱의 단일 코어와 1:1로 같다기보다, 구독 링크가 Clash 호환 형식이면 가져온다는 뜻에 가깝습니다. 그래서 같은 링크라도 Stash에서 보이는 설정 단위와 Shadowrocket의 노드 목록 표현이 완전히 같지는 않을 수 있습니다.

가져오기에 실패하면 Shadowrocket은 대개 짧은 영문·중문 메시지를 띄웁니다. 다운로드 실패만 있고 세부가 없으면, 먼저 시스템 수준에서 해당 도메인에 대한 HTTPS가 막히는지(Safari로 동일 URL 열기)를 확인하세요. 막히지 않는데도 앱만 실패하면, 앱의 가져오기 User-Agent나 구독 제공자의 접근 제어(특정 UA만 허용)를 의심합니다. 이 경우도 UA·403 설명이 그대로 도움이 됩니다.

Shadowrocket에서 TLS 오류가 날 때는 Stash와 마찬가지로 시스템 시각·기업 인증서·서버 체인을 우선 봅니다. 추가로, 일부 사용자는 iCloud 릴레이나 개인 정보 보호 DNS를 켠 상태에서 특정 도메인만 해석이 꼬이는 사례를 겪습니다. 이때는 잠시 해당 기능을 끄고 같은 구독 링크를 다시 시험해 볼 가치가 있습니다.

TLS와 「인증서」 단계: 무엇을 설치해야 할까

검색을 하다 보면 「루트 인증서를 설치하라」는 글이 나오는데, 일반적인 공인 구독 URL을 가져오는 경우에는 사용자가 수동으로 뭔가를 설치하지 않아도 되는 것이 정상입니다. 사용자 측에서 인증서를 추가로 설치해야 하는 대표 경우는 다음과 같습니다. 첫째, 구독이 자체 서명된 HTTPS를 쓰는 폐쇄망에 있을 때입니다. 둘째, 조직에서 발급한 사내 CA를 신뢰하도록 기기를 구성할 때입니다. 셋째, MITM 디버깅 도구를 의도적으로 쓰는 개발 환경입니다.

iOS에서 프로파일로 내려받은 신뢰 루트는 설정의 인증서 신뢰 설정에서 별도로 「완전한 신뢰」를 켜야 하는 경우가 있습니다. 여기를 빠뜨리면 앱은 여전히 TLS 검증에 실패합니다. 반대로, 테스트 후 불필요한 신뢰 루트를 남겨 두면 보안상 좋지 않으므로, 사용 목적이 끝나면 프로파일을 제거하는 습관을 권장합니다.

한편, 「앱이 MITM용 로컬 인증서를 설치하라」고 안내하는 경우는 구독 다운로드와는 다른 기능(HTTPS 디코딩 등)일 때가 많습니다. 화면의 단계 이름이 비슷해 혼동하기 쉬우니, 지금 맞추려는 문제가 원격 구독 URL 가져오기인지, 트래픽 분석용 로컬 신뢰인지부터 구분하세요.

가져오기는 됐는데 노드가 비어 있을 때

원격 응답이 200 OK인데도 노드가 비어 있으면, 본문이 Clash가 기대하는 형식이 아니거나 Base64 디코딩에 실패했을 가능성이 큽니다. HTML 오류 페이지나 「만료되었습니다」 같은 짧은 텍스트만 오면 파서는 아무 프록시도 만들지 못합니다. Safari에서 보이는 내용과 앱이 받은 내용이 같은지, 길이가 비정상적으로 짧지 않은지 비교해 보세요.

또 한 가지는 구독 갱신은 성공했지만 규칙·그룹 이름이 꼬여 UI에서 빈 그룹만 보이는 경우입니다. 이때는 원격 목록 자체가 비어 있는지, 아니면 로컬 프로필이 다른 이름을 참조하는지를 나눕니다. 후자는 구독·노드 유지보수 가이드에서 말하는 프로필 정리와 맞닿아 있습니다. 앱 캐시를 지우기 전에, 원격 응답이 유효한지부터 확인하면 시간을 아낍니다.

한눈에 보는 점검 순서

  1. Safari로 같은 구독 링크를 열어 본문 형식·로그인 리다이렉트 여부를 본다.
  2. 날짜·시간·시간대를 자동으로 맞춘다.
  3. Wi-Fi와 셀룰러를 바꿔 망별 차단이 있는지 본다.
  4. Stash·Shadowrocket 각각에서 TLS·타임아웃·HTTP 코드 힌트를 구분한다.
  5. 403·UA 이슈가 의심되면 404·403·UA 가이드의 순서를 적용한다.
  6. 기업 프로파일·추가 신뢰 인증서가 있으면 TLS 경로를 재평가한다.
  7. 성공 코드인데 노드가 없으면 응답 형식·프로필 참조 이름을 먼저 고친 뒤 캐시를 비운다.

정리와 다음 단계

iPhone에서 Clash 구독 가져오기가 실패할 때, 원인은 대개 (1) 잘못 복사되었거나 만료된 구독 링크, (2) 망·DNS·시간 때문에 깨지는 TLS, (3) 서버가 돌려준 본문이 기대한 목록 형식이 아닌 경우로 수렴합니다. Stash와 Shadowrocket은 화면과 용어가 달라도, 로그에 찍힌 단어가 타임아웃인지 인증서인지 HTTP 코드인지로 다음 조치가 달라집니다. 한 번에 모든 스위치를 바꾸기보다, 위 체크리스트처럼 한 단계씩 좁히면 재현과 되돌리기가 쉽습니다.

장기적으로는 구독과 노드를 주기적으로 점검하는 습관이, 급할 때 앱을 삭제했다가 다시 까는 일을 줄여 줍니다. 환경별로 자주 묻는 연결 문제는 FAQ에서도 다루고 있으니, 증상이 겹칠 때 함께 보시길 권합니다.

데스크톱·Android에서 쓰던 프로필을 그대로 기대하기보다, iOS 클라이언트가 지원하는 항목과 제한을 이해하고 나면 같은 TLS 오류라도 훨씬 덜 답답하게 느껴집니다. 반대로 말하면, 모바일에서 한 번 통과한 절차를 메모해 두면 가족 기기에 그대로 옮기기도 쉬워집니다.

→ Clash를 무료로 다운로드하고, 데스크톱에서 구독·규칙·로그를 한 화면에 맞춰 둔 뒤 iOS 앱과 병행하면 원인을 더 빨리 가를 수 있습니다.