1. 어떤 증상부터 네트워크를 의심할까
character.ai 로고나 목록 UI는 보이는데 캐릭터 방에 들어간 뒤 채팅 입력창만 회색으로 남거나, 전송 직후 응답이 오지 않고 로딩 아이콘만 도는 경우가 대표적입니다. 모바일 앱에서는 동일 계정인데도 웹만 되고 앱만 실패하거나, 반대로 한쪽만 간헐적으로 끊기는 패턴도 흔합니다. 개발자 도구·앱 네트워크 로그에 실패한 호스트 이름이 남으면, 원인 후보를 “노드 품질” 하나로 줄이기 어렵습니다. Character.AI는 HTML·정적 자원과 실시간 대화·스트림이 서로 다른 FQDN·CDN으로 갈라질 수 있어, character.ai 한 줄만 시스템 프록시에 넣었다고 해서 전 구간이 같은 규칙 분류에 묶이지 않을 수 있습니다.
또한 url-test 정책 그룹이 짧은 주기로 최저 지연 노드를 바꾸면 출구 IP가 흔들려 세션·쿠키·리다이렉트 체인이 어긋나 “갑자기 로그아웃되거나 다시 로딩만 돈다”는 체감으로 나타나기도 합니다. 서비스 측 이용 제한·계정 상태·지역 정책은 프록시만으로 해결되지 않는 경우가 많습니다. 본문에서는 사용자가 프로필에서 조정할 수 있는 규칙 순서·노드 고정·DNS·브라우저 DoH 충돌 여부를 중심으로 설명합니다. TLS 단계에서 막히는 경우는 TLS Handshake 글과, fake-ip 이슈는 fake-ip 트러블슈팅 글을 함께 보세요. Windows 클라이언트 선택은 Clash Verge 비교를, 문법은 설정 가이드와 함께 보면 적용이 빠릅니다.
2. ChatGPT·Claude·Perplexity 글을 그대로 가져오면 안 되는 이유
저장소의 ChatGPT·OpenAI 글은 openai.com·chatgpt.com 계열을, Claude·Anthropic 글은 anthropic.com·claude.ai 등을, Perplexity 글은 perplexity.ai 계열을 다룹니다. Google Gemini 글은 googleapis.com·gemini.google.com 등 Google 네임스페이스가 중심입니다. Character.AI는 브랜드·제품 구조가 위 서비스들과 다르므로, “AI용 규칙”이라는 이유만으로 다른 벤더 규칙에 자동 합류한다고 가정하면 안 됩니다. 실제로는 character.ai 본문과 별도 최상위 도메인의 미디어·분석·CDN 호스트가 함께 등장할 수 있어, 네트워크 탭에 찍힌 이름을 규칙에 반영하는 편이 안전합니다.
DOMAIN-KEYWORD,character처럼 지나치게 넓은 키워드는 다른 사이트·추적 도메인까지 끌어올 위험이 있어, 가능하면 본인 환경에서 관측한 DOMAIN-SUFFIX·DOMAIN 위주로 좁히는 편이 좋습니다. 앱·웹 빌드가 바뀔 때마다 하위 호스트가 늘 수 있으므로, 장애가 날 때마다 개발자 도구에 찍힌 정확한 FQDN을 규칙 목록에 덧붙이는 습관이 장기적으로 유지보수 비용을 줄입니다.
3. Character.AI 웹·앱이 자주 쓰는 호스트(개념)
브라우저에서 character.ai를 열면 HTML·자바스크립트 번들, 아이콘·폰트, 그리고 대화 유지를 위한 API·WebSocket(wss) 요청이 서로 다른 이름으로 이어질 수 있습니다. 일부 정적 자원은 글로벌 CDN이나 서드파티 호스트로 나가며, 이때 해당 호스트가 DIRECT나 다른 지역 노드로만 나가면 “페이지는 빠른데 채팅만 느리다”는 패턴이 됩니다. 모바일 앱은 OS 수준 DNS·프라이빗 릴레이·다른 VPN과의 상호작용까지 같이 봐야 할 때가 있습니다.
본문은 특정 시점의 호스트 목록을 고정값으로 제시하지 않습니다. 대신 장애 시 개발자 도구 Network에서 실패·지연한 요청의 호스트명을 순서대로 적고, Clash 연결 로그에서 어떤 정책에 매칭됐는지 대조하는 절차를 권장합니다. 팀 단위로 쓰는 경우 스테이징 프로필에서 먼저 규칙을 검증하고, 운영 프로필에 반영하면 롤백이 쉽습니다.
웹과 앱의 차이
동일 서비스라도 웹뷰·네이티브 스택에 따라 User-Agent·TLS 핑거프린트·DNS 경로가 달라질 수 있습니다. “웹만 된다”면 앱이 시스템 프록시를 우회하는지, 반대로 “앱만 된다”면 브라우저 DoH나 확장이 개입하는지부터 나누는 것이 좋습니다. 이때도 계정·구독·이용 약관에 따른 제한 가능성은 열어 두어야 합니다.
4. Clash 규칙 분류로 Character.AI 도메인 묶기
Clash(Mihomo 계열)에서는 RULE 모드에서 위에서 아래로 첫 매칭이 적용됩니다. Character.AI 관련 호스트를 하나의 정책 그룹(예: CHARACTER-AI)에 모으려면 구체적인 DOMAIN-SUFFIX를 위에 두고, 넓은 규칙은 아래에 두는 순서가 안전합니다. 아래는 이해를 돕기 위한 예시 스켈레톤이며, 실제 제품 변경에 따라 하위 도메인·CDN이 달라질 수 있으니 반드시 본인이 캡처한 호스트로 보강하세요.
rules:
- DOMAIN-SUFFIX,character.ai,CHARACTER-AI
- MATCH,OthersDOMAIN-SUFFIX,character.ai는 같은 접미사 아래의 여러 하위 호스트를 한 번에 묶는 데 유용합니다. 그러나 네트워크 탭에 다른 최상위 도메인이 보이면 그때마다 DOMAIN-SUFFIX 또는 DOMAIN 줄을 추가해야 합니다. 구독에서 내려받은 대형 규칙 분류 세트를 쓰는 경우, “광고 차단”·“지역 직결” 같은 상위 규칙에 먼저 걸려 아래 줄이 실행되지 않는지 연결 로그로 확인하세요. proxy-groups에 CHARACTER-AI 이름의 그룹을 실제로 정의해 두어야 하며, 이름이 어긋나 있으면 구문 오류나 의도치 않은 REJECT로 이어질 수 있습니다. rule-providers로 외부 목록을 쓴다면 갱신 주기와 우선순위를 팀 표준에 맞춰 문서화해 두면 온콜 대응이 수월합니다.
5. 노드 선택과 정책 그룹
노드 선택은 ping이 가장 낮은 서버가 항상 정답은 아닙니다. 동일 구독이라도 회선 혼잡·피어링 구간에 따라 TLS 왕복과 패킷 손실이 달라지고, 긴 스트리밍 응답에서는 끊김이 체감으로 드러납니다. url-test가 짧은 주기로 최저 지연 노드를 바꾸면 출구 IP가 흔들려 세션 안정성이 떨어질 수 있으니, 증상이 있을 때는 select로 한 노드를 고정하거나 fallback 계열로 바꿔 비교해 보세요.
시스템 프록시만 쓰는 브라우저와 TUN으로 전체 트래픽을 덮는 구성은 증상 패턴이 다릅니다. TUN을 켠 상태에서는 로컬 망 예외·Windows 방화벽·다른 VPN과의 충돌을 함께 봐야 하므로 TUN 문서와 TUN 트러블슈팅 글을 참고하세요. 사내망에서는 분할 터널링 정책과 충돌하지 않는지 보안 팀 가이드도 한 번 짚는 것이 좋습니다.
6. DNS·DoH·fake-ip가 만드는 착시
규칙이 맞아 보여도 DNS 조회가 먼저 실패하면 애플리케이션은 프록시를 타기 전에 끊깁니다. fake-ip 모드에서는 도메인과 가상 IP 매핑 타이밍이 민감해, OS·브라우저 DoH·사내 리졸버가 동시에 개입하면 “간헐적으로만 된다”는 패턴이 나올 수 있습니다. character.ai가 의도와 다른 리졸버로 풀리면 엣지까지의 경로가 달라져 지연이 커지기도 합니다.
점검 순서로는 (1) Clash DNS 패널의 리졸버·폴백 설정, (2) 운영체제 캐시, (3) 브라우저 전용 DoH를 차례로 확인합니다. DIRECT로 나가야 할 내부 호스트가 오탐으로 프록시에 탄 경우에도 비슷한 증상이 나오므로, 코어 로그에서 어떤 규칙에 매칭됐는지를 습관적으로 읽는 것이 중요합니다. 터미널 도구가 시스템 프록시를 무시한다면 터미널 프록시·환경 변수 글과 병행해 점검하세요. 입문 시 모드 전환 실험은 튜토리얼과 함께 하면 부담이 적습니다.
7. 적용 후 검증 순서
설정을 저장한 뒤에는 (1) 코어 재시작 또는 프로필 핫 리로드, (2) 브라우저에서 Character.AI 채팅 페이지 강력 새로고침, (3) 개발자 도구에서 실패한 호스트에 대해 curl로 TLS 핸드셰이크만 짧게 확인하는 순서가 실무적입니다. GUI 클라이언트는 연결 테스트 기능으로 동일 호스트를 찍어 볼 수 있습니다.
여전히 스피너가 길다면 네트워크 탭에서 실패한 요청의 상태 코드·CORS·WebSocket 종료 사유를 먼저 보고, 그 호스트명을 규칙에 추가합니다. 증상이 특정 시간대에만 반복되면 노드 혼잡과 서비스 측 상태를 함께 의심할 수 있습니다. 이때도 계정 측 제한 가능성을 열어 두고, 지원팀에 문의할 정보(시간대·요청 ID)를 함께 모아 두면 대응이 빨라집니다.
9. 증상별 자가 점검
아래 표는 Character.AI 사용 환경에서 무엇을 먼저 볼지 정리한 것입니다.
| 증상 | 의심 지점 | 조치 |
|---|---|---|
| 페이지는 뜨는데 채팅·스트림만 실패 | WebSocket·API·CDN 호스트 규칙 누락 | 네트워크 탭에서 실패 FQDN 확인 후 규칙 추가 |
| 웹은 되는데 앱만 오류 | 앱이 다른 DNS·프록시 경로 사용 | 앱 트래픽 로그와 Clash 매칭 로그 대조 |
| 간헐적 타임아웃·끊김 | 혼잡한 출구, DNS 흔들림, url-test 전환 | 수동 select·DNS 고정·fallback 실험 |
| 로그인은 되는데 대화만 멈춤 | 실시간 호스트가 다른 정책·노드로 매칭 | 실패 요청 호스트를 동일 그룹으로 묶기 |
LAN에서 Mixed Port를 열어 둔 경우 방화벽·포트 설정과 충돌하지 않는지도 함께 확인하세요.
10. 요약
Character.AI(character.ai)는 랜딩·정적 자원·실시간 대화가 서로 다른 호스트로 갈라질 수 있어, 한 줄짜리 시스템 프록시 설정보다 도메인 기준 규칙 분류와 노드 그룹 실험이 체감 안정성을 좌우합니다. 화면이 비거나 계속 로딩만 돌 때도 네트워크 측에서는 경로 일관성·DNS·브라우저 DoH·출구 전환을 먼저 의심해 볼 수 있습니다.
공유된 규칙 세트를 가져왔더라도 본인 프로필에서의 매칭 순서는 직접 확인하는 것이 안전합니다. 연결 기록과 규칙 테스트가 읽기 쉬운 최신 Mihomo 계열 클라이언트를 쓰면 호스트가 늘어나는 SaaS에 맞춰 유지보수하기에도 유리합니다. ChatGPT·Claude·Perplexity 등 시리즈의 다른 글과 마찬가지로, 브랜드별 FQDN을 분리해 두는 패턴을 반복 적용하는 것이 독자 경로를 통일하는 데 도움이 됩니다.
설치 패키지는 공식 다운로드 페이지에서 받는 것이 혼선이 적고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 됩니다.
→ Clash를 무료로 내려받아 Character.AI·character.ai용 규칙 분류와 노드 정책을 직접 맞춰 보세요