로그인은 되는데 Replit Agent만 계속 재시도합니다. 무엇부터 보나요?

에이전트가 호출하는 GraphQL·장시간 WebSocket 호스트가 다른 규칙에 DIRECT로 빠지지 않는지 Connections에서 확인하고, 브라우저와 동일한 PROXY 그룹으로 맞추세요.

빌드·npm install만 타임아웃일 때는요?

registry.npmjs.org·GitHub tarball·Google 저장소 등 패키지 레지스트리용 DOMAIN-SUFFIX를 Replit 앱 도메인과 분리해 출구를 고정하면 증상이 분리됩니다.

Rule Provider와 직접 DOMAIN-SUFFIX 중 무엇을 쓰나요?

팀에서 검증한 RULE-SET이 있으면 Provider가 유지보수에 유리합니다. 없으면 DOMAIN-SUFFIX로 최소 집합을 만들고 로그로 보강하는 방식이 빠릅니다.

전역 VPN만 켜면 되지 않나요?

가능은 하지만 국내 직통이 필요한 자산까지 느려지고 이중 터널·DNS 꼬임이 나기 쉽습니다. Clash 분할이 목적지별 출구를 명시적으로 맞춥니다.

Replit Agent·Clash WS

1 2026년에도 Replit은 «한 줄 규칙»에 잘 안 맞는 이유

Replit은 브라우저 안에서 코드 편집·실행·호스팅을 한 번에 묶는 클라우드 IDE이고, Replit Agent는 그 위에서 자연어로 리포지토리를 탐색하고 명령을 제안합니다. 제품이 진화하면서 같은 탭 안에서도 트래픽이 replit.com UI, 내부 GraphQL 엔드포인트, 장시간 유지되는 WebSocket, npm·패키지 레지스트리, 때로는 Google·GitHub OAuth로 흩어집니다. 구독에서 내려주는 거대 GEOSITE 한 줄이나 «해외 = 한 그룹»만 쓰면, 브라우저 세션은 살아 있는데 백그라운드 세션만 API 타임아웃으로 끊기는 반쪽 증상이 자주 납니다.

Clash 분할의 목적은 속도 자랑이 아니라 Connections 로그에 찍힌 FQDN마다 의도한 프록시 그룹이 걸리게 만드는 것입니다. DOMAIN-SUFFIX로 최소 집합을 만들고, 팀에 공유 가능한 목록이 있으면 Rule Provider로 갱신 주기를 맡기면 운영 부담이 줄어듭니다. 클라이언트가 없다면 다운로드 페이지에서 GUI를 고른 뒤 아래 순서대로 프로파일에 합치면 됩니다.

2 웹 로그인·Replit 앱 축·패키지 레지스트리를 동시에 맞추기

계정·OAuth: 이메일 로그인과 소셜 로그인은 브라우저가 replit.com, 필요 시 accounts.google.com·github.com·기타 IdP로 이동합니다. 여기서 일부만 프록시를 타면 리다이렉트가 끊기거나 쿠키 도메인이 어긋날 수 있으니, 실제 로그 플로에 나온 호스트를 기준으로 묶는 것이 안전합니다. Google·Microsoft 등 IdP 전체를 Replit 블록에 억지로 넣기보다 Microsoft·Clash류 글에서 쓰는 IdP 분할과 규칙 순서를 맞추세요.

앱·에이전트 축: 편집기·에이전트·협업 채널은 DOMAIN-SUFFIX,replit.com 아래 여러 서브도메인과 WebSocket 업그레이드가 한 세트로 움직입니다. UI는 직통이고 API만 막히면 «로그인 됐는데 Agent만 스피너» 패턴이 나옵니다. 이 갈래는 PROXY_REPLIT 같은 이름으로 고정해 두고 변경을 한곳에서 추적하세요.

빌드·패키지: 컨테이너 안의 npm install·pip는 registry.npmjs.org·files.pythonhosted.org·pypi.org 등 레지스트리를 향합니다. 이 축을 Replit UI와 같은 그룹에 억지로 합치면, 특정 지역 CDN만 불안정할 때 전체 제품이 느려 보입니다. 레지스트리는 PROXY_DEV_ARTIFACTS처럼 분리해 두면 원인 설명이 쉬워집니다.

증상 언어로 갈래를 나누기 «브라우저 탭은 살아 있다»는 말은 OAuth는 성공했지만 장시간 WebSocket이나 백엔드 API가 다른 정책으로 새고 있다는 뜻일 때가 많습니다. 먼저 Connections에서 프로토콜과 호스트를 스냅샷으로 남기세요.

3 DOMAIN-SUFFIX·규칙 순서에서 자주 나는 실수

실무에서 먼저 검토할 접미사는 DOMAIN-SUFFIX,replit.com과 미리보기·배포에 쓰이는 DOMAIN-SUFFIX,repl.co입니다. 과거 호환으로 repl.it 리다이렉트가 로그에 남을 수 있으니 팀 환경에서 실측이 있으면 함께 넣으세요. 애널리틱스·오류 리포팅 서브도메인이 보이면 같은 Replit 정책으로 둘지, 별도 분석 그룹으로 뺄지 합의하면 됩니다.

패키지·소스는 DOMAIN-SUFFIX,npmjs.org·DOMAIN-SUFFIX,nodejs.org·DOMAIN-SUFFIX,github.com·DOMAIN-SUFFIX,githubusercontent.com 등으로 넓혀 갑니다. 회사 레지스트리 미러를 쓴다면 그 FQDN을 우선 추가하세요. Rule Provider에 공개 RULE-SET을 그대로 얹을 때는 Replit 전용 줄이 더 앞에 오도록 순서를 확인합니다. 맨 위의 광범위 MATCH가 먼저 나오면 의도와 다른 노드가 흡수합니다.

DOMAIN-KEYWORD,replit 같이 키워드만 쓰면 무관한 호스트까지 잡혀 디버깅이 어려워집니다. 접미사와 검증된 RULE-SET을 우선하고 키워드는 임시 진단용으로만 쓰는 편이 낫습니다. DNS·FakeIP 설계는 DNS 유출 방지 가이드와 맞추면 이름 해석과 TCP 출구 불일치로 인한 가끔 실패를 줄일 수 있습니다.

4 Rule Provider와 `rules:` 예시

아래는 개념 스니펫입니다. proxy-groups와 노드 이름은 본인 프로파일에 맞추고, rule-providers의 url은 신뢰하는 목록으로 교체하세요. 원격 목록이 없으면 RULE-SET 줄을 삭제하고 DOMAIN-SUFFIX만으로 시작해도 됩니다.

config.yaml (snippet)

# Example only — merge with your full profile
proxy-groups:
  - name: PROXY_REPLIT
    type: select
    proxies:
      - AUTO-BEST
      - DIRECT
  - name: PROXY_DEV_ARTIFACTS
    type: select
    proxies:
      - AUTO-BEST
      - DIRECT

rule-providers:
  replit-stack:
    type: http
    behavior: classical
    url: "https://example.com/rules/replit-stack.txt"
    path: ./ruleset/replit-stack.yaml
    interval: 86400

rules:
  - RULE-SET,replit-stack,PROXY_REPLIT
  - DOMAIN-SUFFIX,replit.com,PROXY_REPLIT
  - DOMAIN-SUFFIX,repl.co,PROXY_REPLIT
  - DOMAIN-SUFFIX,npmjs.org,PROXY_DEV_ARTIFACTS
  - DOMAIN-SUFFIX,github.com,PROXY_DEV_ARTIFACTS

직접 합성 시 주의 공개 RULE-SET이 DIRECT를 강제하는 줄을 포함하면 에이전트 호스트가 직행해 WebSocket이 끊길 수 있습니다. 가져온 파일을 합치기 전에 Replit 관련 줄이 어떤 정책으로 끝나는지 확인하세요.

5 WebSocket·GraphQL·API 타임아웃을 노드와 규칙으로 해석하기

Replit Agent류 기능은 HTTP/1.1 업그레이드나 HTTP/2 스트림 위에 긴 세션을 올립니다. 중간 회선이 끊기면 클라이언트는 자동 재연결을 시도하지만, 매번 다른 노드로 붙으면 서버 입장에서는 세션 흔들림으로 보일 수 있습니다. 진단 때는 노드를 한 가지로 고정하고 같은 시간대 로그를 비교하세요.

타임아웃 메시지가 TLS 핸드셰이크 직후에 난다면 규칙보다 회사 방화벽·SNI 필터를 의심합니다. 애플리케이션 레이어까지 응답이 왔다가 중간에 멈추면 패킷 손실이나 UDP 경로 문제일 수 있어, 동일 노드에서 다른 사이트 장시간 연결 테스트를 병행하면 구분에 도움이 됩니다. 로그에 찍힌 호스트가 DIRECT로 나가는데 해당 지역에서 서비스가 불안정하면 우회 그룹으로 옮기는 것이 맞습니다.

API 호출이 짧고 WebSocket만 길다면, 동일한 PROXY_REPLIT를 쓰되 노드 지연이 허용 범위인지 별도로 확인하세요. 지연이 크면 에이전트 응답이 느리게 느껴져 «타임아웃»으로 오해할 수 있습니다.

6 클라우드 빌드·실시간 미리보기가 따로 끊길 때

빌드는 원격 러너가 외부 패키지·컨테이너 레지스트리에 닿는 경로와, 로컬 브라우저가 빌드 로그 스트림을 구독하는 경로가 다릅니다. 로그 UI만 멈추면 WebSocket·SSE류 구간을, 패키지 단계만 실패하면 레지스트리 접미사를 우선 의심하세요. 실시간 미리보기는 종종 별도 서브도메인·포트로 열리므로 Connections에서 실제 FQDN을 한 번씩 확인하는 것이 안전합니다.

팀에서 사내 아티팩트 미러나 승인된 레지스트리만 허용한다면, Replit 컨테이너가 그 주소로 나가도록 회사 DNS와 Clash 규칙을 동시에 맞춰야 합니다. 정책 충돌을 네트워크 도구만으로 우회하려 하지 말고, 보안·플랫폼 담당자와 경로를 합의하는 편이 재발을 줄입니다.

7 브라우저 TUN·시스템 프록시·DNS를 통일하기

Chromium 기반 브라우저는 OS 프록시를 따르는 경우가 많지만, 별도 데스크톱 앱이나 실험적 런타임이 섞이면 트래픽이 빠져 나갈 수 있습니다. TUN 모드로 커널 라우팅을 Clash에 맡기면 규칙 엔진을 한곳에서 볼 수 있어 출구 불일치 진단이 쉬워집니다. 다만 회사 전역 VPN과 이중 터널이 되면 지연이 커질 수 있으니 업무 정책 범위 안에서만 켜세요.

DoH·FakeIP·fallback DNS가 꼬이면 규칙은 맞는데 세션만 이상해 보일 수 있습니다. 노드를 바꿀 때마다 같은 호스트의 성공·실패가 들쭉날쭉하면 DNS와 TCP를 분리해 점검하세요. 재현 가능한 로그를 남기면 온콜 대응에도 도움이 됩니다.

최소 재현 체크리스트 동일 노드·동일 DNS로 고정한 뒤, (1) 로그인 (2) 새 Repl 생성 (3) Agent 질문 한 번 (4) 패키지 설치 (5) 미리보기 새로고침을 같은 순서로 반복하면 어느 단계에서 호스트가 갈라지는지 빠르게 보입니다.

8 계정·토큰·조직 정책

연결이 되어도 401·403·쿼터 초과는 토큰 만료·팀 정책·결제 상태 문제일 수 있습니다. API 키·세션 쿠키를 공용 저장소에 올리지 마세요. 본문은 경로 가용성과 Clash 규칙만 다루며, 지역 규정·고용 계약·서비스 약관 해석을 대신하지 않습니다.

학교·회사 네트워크 교육기관 필터나 사내 프록시가 SaaS를 제한하는 환경에서는 분할 규칙만으로 해결되지 않을 수 있습니다. 허용 목록 신청이 필요한지 항상 내부 정책을 먼저 확인하세요.

9 자주 묻는 질문

Agent만 스피너: GraphQL·WS 호스트가 다른 정책으로 DIRECT인지 Connections에서 확인하고 PROXY_REPLIT로 통일하세요.
npm만 타임아웃: npmjs.org·tarball 호스트를 PROXY_DEV_ARTIFACTS로 분리했는지 보세요.
로그인 루프: IdP(Google/GitHub)와 Replit UI가 같은 출구인지, 쿠키 도메인이 맞는지 브라우저 개발자 도구로 점검하세요.
Rule Provider 믿을 만한가: 출처와 갱신 주기를 팀이 검토하고, 핵심 줄은 로컬에 복제해 두면 장애 시 롤백이 쉽습니다.

10 정리

2026년 클라우드 IDE에서 Replit Agent를 안정적으로 쓰려면 «스위치 하나」보다 호스트 묶음을 유지보수 가능하게 두는 편이 낫습니다. Clash 분할에서 DOMAIN-SUFFIX와 Rule Provider로 replit.com 축과 패키지 레지스트리·OAuth 축을 나누고, WebSocket·API가 기대한 프록시 그룹을 타는지 Connections로 검증하면 API 타임아웃 원인을 빠르게 좁힐 수 있습니다.

순정 브라우저 확장이나 단일 전역 VPN만으로도 통과되는 경우는 있지만, 규칙을 한눈에 보기 어렵고 국내 자산이 함께 느려지는 경우가 많습니다. GUI가 단순한 클라이언트는 고급 분할을 숨기거나 구독 포맷에 종속되기도 해서, 장기적으로는 Mihomo 계열과 Rule Provider를 직접 다룰 수 있는 구성이 유리합니다. 반면 Clash Verge Rev처럼 TUN·Mihomo·다중 프로파일을 한 화면에서 다루는 도구는 Replit뿐 아니라 Codex CLI 같은 인접 워크플로와도 같은 패턴으로 이어 붙이기 쉽습니다. 비슷한 고통을 줄이고 싶다면 공식 다운로드 페이지에서 설치 후 위 스니펫을 프로파일에 맞게 편입해 보시길 권합니다.

릴리스 아티팩트는 항상 사이트의 검증된 경로를 우선하세요. 커뮤니티 빌드도 참고 가치가 있지만 버전 관리 측면에서는 분명한 배포 채널이 덜 위험합니다.

→ Clash 무료 다운로드 후 Replit 규칙을 적용해 보세요