증상: 피드·이미지·API만 불안정할 때
자주 보이는 그림은 다음과 비슷합니다. 메인 피드는 열리는 것 같은데 썸네일이 비거나 계속 스피너만 돌고, 댓글·검색·쇼핑 탭은 또 다른 호스트에 붙다가 로그에는 i/o timeout·connection reset이 섞입니다. 혹은 웹뷰·공유 링크(딥링크)는 되는데 네이티브 클라이언트만 이상하거나, 반대로 시스템 DNS는 정상인데 Clash FakeIP 흐름에서만 규칙과 실제 패킷이 달라 보입니다. 이때 “노드가 나빠서”로만 몰기 전에, 같은 노드로 curl HTTPS는 되는지·앱이 QUIC(UDP 443)로 우회하는지부터 가르는 편이 빠릅니다.
Xiaohongshu 계열 서비스는 로그인·추천·광고·미디어 CDN이 서로 다른 도메인 접미사에 나눠 잡혀 있고, 지역·A/B·앱 빌드에 따라 이름이 바뀌기도 합니다. 그래서 이 글에서는 고정 화이트리스트를 통째로 제시하기보다, 연결 로그에 찍힌 실제 이름을 DOMAIN-SUFFIX로 올리는 루프를 기본으로 합니다.
앱, 웹, 공유·딥링크는 트래픽 층이 다르다
둘째, RedNote·小红书 앱은 (1) 앱스토어·푸시·분석, (2) API·그래프QL류 엔드포인트, (3) 이미지·동영상 CDN·객체 스토리지로 층이 갈라집니다. 어떤 층만 DIRECT로 떨어지고 나머지는 PROXY에 걸리면, 화면은 열려도 미디어가 비는 부분 실패가 납니다. 시스템 프록시를 따르는지·TUN 캡처가 필요한지도 앱마다 달라 TUN 가이드와 맞춰 보면 경계를 줄일 수 있습니다.
Disney+·MCP 글과 무엇이 다른가
Disney+ 지역 글은 스트리밍·DRM·지역 메시지에 초점을 둡니다. MCP 글은 IDE·원격 모델 API입니다. 본문은 소셜 피드·숏폼·이커머스 웹뷰에 가까운 호스트를 다루므로, 도메인 집합·업데이트 주기·지역 정책이 완전히 다릅니다. 같은 Clash 분류 도구를 써도 “베끼는 규칙 블록”은 통하지 않고, 로그에서 이름을 고정하는 쪽이 안전합니다.
1도메인·API·CDN을 한 묶음으로 잡는 분류
rules는 위에서 아래로 첫 매칭에서 멈춥니다. 넓은 GEOIP,CN나 거대 IP-CIDR이 세밀한 DOMAIN-SUFFIX보다 위에 있으면, “이름은 맞는데 정책이 뒤틀리는” 화면이 납니다. 팀 Rule Provider에 소셜/쇼핑 카테고리를 쓰더라도, 해외판 앱 전용 엔드포인트는 공개 목록에 없을 수 있으니 사용자 규칙을 짧게 덧댑니다.
아래는 개념용 스케치이며, PROXY는 본인 proxy-groups 이름으로 바꾸고 접미사는 실측 로그로 채워야 합니다. 공개적으로 자주 쓰이는 xiaohongshu.com·xhscdn 계열이 보일 수 있으나, 빌드마다 달라질 수 있음을 가정하세요.
# Sketch — replace PROXY; suffixes from your live connection log
rules:
- DOMAIN-SUFFIX,sns.example.xiaohongshu.com,PROXY
- DOMAIN-SUFFIX,example-cdn.xhscdn.com,PROXY
- DOMAIN-SUFFIX,edge.share.example.com,PROXY
- GEOIP,KR,DIRECT
- MATCH,PROXYSniffer를 켠 상태에서 SNI·도메인이 잡히는지·끈 상태에선 IP만 보이는지도 함께 봅니다. IP만 보이면 Sniffer 가이드와 quic·UDP 443 관련 policy를 팀 정책에 맞게 조정하세요.
요약: RedNote / 小红书 류는 CDN·광고·로그인이 서로 다른 이름을 쓰기 쉬워, 한 줄 DOMAIN 복붙보다 “로그 → 한 줄씩” 루프가 유지 보수에 유리합니다.
2DNS: FakeIP·DoH·직접/DIRECT 오매칭
enhanced-mode fake-ip를 켠 프로필에서는, 코어 밖(공유기 dnsmasq·Android 프라이빗 DNS 등)에서 먼저 해석돼 redir-host·FakeIP와 엇갈리면 “규칙은 PROXY인데 앱이 DIRECT로 보내는” 괴이 현상이 납니다. Meta 코어 DNS 유출 방지 가이드에 맞춰 dns의 DoH·nameserver-policy·use-hosts를 먼저 정렬하세요. 사내/가정 LAN 전용 이름이 섞이면 fake-ip-filter로 직접 연결 도메인을 빼는 것도 같이 설계합니다.
질의 결과를 의심할 때는 dig·nslookup로 동일 호스트의 응답을 보고, Clash 로그의 DNS 줄과 타임스탬프를 맞춥니다. FakeIP로 잡힌 IP가 필터에 걸려 실제 해석으로 못 가는지도 확인합니다. 해외·국내 스토어 계정을 섞어 쓰는 경우, 앱이 기대하는 지역과 노드 출구가 어긋나면 로그인·결제만 터지는 패턴도 있어, 규칙만이 아니라 프록시 그룹 지역을 함께 봅니다.
3TUN·QUIC·앱이 우회하는 경로
시스템 프록시만 켠 macOS·Windows에서 일부 앱은 SOCKS·HTTP를 무시하고 직접 소켓을 열 수 있습니다. RedNote 해외 빌드도 QUIC을 켜 두면 도메인 규칙이 UDP 경로에 적용되지 않는 경우가 있어, 증상 재현 시 QUIC 비활성 실험·TUN으로 캡처 범위를 넓히는 절차를 FlClash Android 가이드·데스크톱 클라이언트 문서와 병행해 보세요. Windows 초기 설치는 Windows 설치 글과 맞춰 두면 이후 트러블슈팅이 단순해집니다.
VPN·다른 가상 NIC과 TUN을 겹쳐 쓰면 DNS만 꼬이는 경우가 많으니, 동시 사용을 잠시 끄고 다시 재현해 보는 것이 저렴한 실험입니다.
4연결 로그로 사실을 고정하기
DNS·rules를 손본 뒤에는 로그에서 (1) 최종 정책 이름, (2) 체인·업스트림, (3) 지연·에러 코드를 기록해 두세요. 피드 새로고침·검색·쇼핑 탭을 바꿀 때마다 새로 뜨는 호스트를 규칙 후보에 올리고, 변화를 확인합니다. 외부 대시보드를 쓰면 Yacd로 활성 연결을 시각화하는 것도 좋습니다. 변수는 한 번에 하나만 바꿔야 원인이 빨리 좁혀집니다.
데이터·배터리 세이빙·광고 차단 앱이 DNS를 가로채는 경우, Clash와 충돌하는지도 점검하세요. “다른 소셜은 되는데 이 앱만”이면, 충돌 앱이 특정 패키지에만 VPN API를 거는지도 봅니다(안드로이드·iOS 프로필 설명을 참고).
준수·개인정보
본문은 네트워크 분류·DNS 정렬만을 다룹니다. 소속 조직의 보안·규정·거주 국가 법을 준수하고, 업무 장비에서는 IT 승인을 받은 뒤 프록시·스니퍼·로그 수집을 적용하세요. RedNote·小红书 서비스 약관·개인정보 처리는 공식 문서를 따릅니다.
오픈소스와 설치 패키지
Mihomo(Clash Meta) 코어 소스는 GitHub에서 열람할 수 있으나, 클라이언트 설치 파일의 주 진입점은 이 사이트 다운로드 페이지를 권장합니다. 릴리스 직링크는 신뢰·버전 확인용으로 두고, 실제 설치는 허브에서 플랫폼별로 고르면 혼선이 줄어듭니다. 전체 옵션 지도는 문서·설정 허브와 함께 보세요.
주의: 타인 계정·콘텐츠 무단 수집·재배포는 약관·법 위반이 될 수 있습니다. 네트워크 설정은 본인 기기·합법 범위 안에서만 조정하세요.
맺음말
RedNote·Xiaohongshu(小红书)는 해외·국내 앱 스토어·계정 조합에 따라 피드·CDN·API가 서로 다른 이름과 지역 정책을 타는 경우가 많습니다. Clash로 이를 다루는 핵심은 감으로 노드만 갈아끼우는 것이 아니라, DNS를 먼저 정렬하고 FakeIP·직접 연결 필터·분류 순서를 로그와 맞춘 뒤, 관측된 도메인을 최소 출구로 올리는 반복입니다. 이렇게 해 두면 크로스보더 소셜이 업데이트돼도 같은 체크리스트를 다른 앱에 이식하기 쉽습니다.
다른 프록시 도구에 비해 Meta 계열은 정책 이름과 로그의 대응이 읽기 쉬운 편이라, “가끔만 느리다”를 재현 가능한 사실로 바꾸기에 유리합니다. 설치 경로를 통일하고 싶다면 GitHub 릴리스 직링크보다 사이트 허브를 쓰는 편이 독자에게 혼선이 적습니다.