증상: 웹은 되는데 작업·API만 불안정할 때
다른 해외 사이트는 나쁘지 않은데 Manus 웹만 입력 반응이 느리거나, 에이전트 작업 진행 바가 오래 멈춘 뒤 타임아웃되는 패턴은 흔합니다. 서버 측 대기열이 원인일 수도 있지만, 클라이언트 쪽에서는 호스트가 여럿으로 쪼개진다는 점을 먼저 의심하는 편이 디버깅 비용이 적습니다. 메인 UI는 manus.im 일대를 쓰는 경우가 많고, 로그인·결제·문서·CDN·실시간 진행(WebSocket·SSE류)은 다른 하위 도메인이나 제3자 호스트로 나뉠 수 있습니다. API·데스크톱 앱·CLI는 브라우저와 다른 경로로 나가 분류 규칙이나 OS 시스템 프록시를 타지 않으면 “웹만 되고 나머지는 끊김”처럼 보이기도 합니다.
한쪽 호스트만 국내 직접 연결(DIRECT)이 되고 다른 쪽만 우회가 필요한 환경이라면, 규칙 순서가 꼬여 세션이 중간에 끊길 수 있습니다. 터미널·백그라운드 프로세스까지 같은 파이프에 올리려면 Clash Verge Rev TUN 모드 가이드를 함께 보는 것이 좋고, Windows 초기 설치는 Windows용 Clash Verge Rev 설치 가이드를 먼저 밟는 편이 실수가 적습니다. 긴 작업·스트리밍 응답은 지연이 낮아 보여도 패킷 손실이 있으면 체감이 크게 나빠지므로, “규칙은 맞는데 끊긴다”면 출구 노드 품질과 동시에 DNS 경로도 함께 보세요.
이 글은 Manus “기능 리뷰”가 아닙니다
과금·크레딧·작업 한도·공식 상태 페이지는 Manus 공지가 가장 정확합니다. 여기서 다루는 것은 네트워크 스택입니다. 즉, 어떤 도메인이 어떤 정책 그룹을 타야 하는지, DNS 응답이 규칙 매칭과 맞는지, FakeIP와 스니퍼 설정이 충돌하지 않는지, 필요하면 특정 구간만 직접 연결로 고정할지입니다. 이 관점을 유지하면 동일한 절차를 다른 클라우드 에이전트·LLM 제품에도 이식하기 쉽습니다.
1Manus 관련 호스트 식별하기
고정된 “영구 정답 목록”보다 본인 환경에서 관측한 호스트를 우선합니다. 브라우저 개발자 도구의 Network 탭에서 manus로 필터링하면 웹 접속 세션이 실제로 붙는 이름을 확인할 수 있습니다. 작업 진행·알림이 실시간이면 wss:// 또는 eventsource류 엔드포인트가 따로 잡히는 경우가 많으니, 끊길 때마다 호스트를 메모해 두세요. API 클라이언트는 실패 로그에 URL이 그대로 남는 경우가 많습니다. 공개적으로 자주 보이는 이름으로는 메인 사이트 manus.im이 있으나, 제품 업데이트에 따라 API 전용 호스트·CDN 접두사가 바뀔 수 있으므로 관측을 기본으로 삼는 것이 안전합니다.
OAuth·결제 흐름이 DIRECT인데 본체만 PROXY인 식으로 갈라지면 쿠키·리다이렉트 루프가 생기기도 하므로, 인증 전체를 한 번에 관측해 보는 것이 좋습니다. 데스크톱 앱만 별도 출구로 보내고 싶다면 PROCESS-NAME 규칙 가이드를 참고하되, 우선은 호스트 단위로 패턴을 잡는 편이 재현성이 높습니다.
2Clash 분류 규칙 최소 예시
아래는 설명용 illustration입니다. 실제 PROXY 자리에는 구독 프로필의 정책 그룹 이름을 넣고, 상위에 이미 GEOIP·MATCH가 있다면 위치를 조정하세요. Network 탭에서 본 이름에 맞게 줄을 추가·삭제하세요.
# Minimal illustration — replace PROXY with your policy group
rules:
- DOMAIN-SUFFIX,manus.im,PROXY
# 관측으로 추가 예: API 전용 호스트, CDN, 인증·결제 도메인 등
- MATCH,DIRECT
RULE-SET이나 Rule Provider로 묶어 두면 엔드포인트가 늘어날 때 한 파일만 갱신하면 됩니다. 대규모 세트를 그대로 쓰면 매칭 비용이 늘 수 있으니, Manus만 작은 사용자 규칙 파일로 관리하는 방식도 현실적입니다. 규칙 세트 선택은 ACL4SSR과 Loyalsoldier 비교 글의 기준을 참고하세요.
웹·작업 큐·API를 나누고 싶을 때
동일한 상위 도메인 아래에서도 경로가 달라 호스트 단위 분리가 어렵다면, 우선 한 정책 그룹으로 통일해 안정성을 확보한 뒤 로그로 병목 호스트만 추려 내는 방식이 디버깅 비용을 줄입니다. “API만 다른 노드”를 쓰고 싶다면 관측된 API 호스트를 더 앞에 두는 식의 세밀한 우선순위가 필요합니다. 이때도 DNS가 규칙이 기대한 이름과 다르게 해석되면 매칭이 빗나가므로, 다음 단계의 DNS 점검과 함께 보세요.
3정책 그룹·노드와 연결 안정성
연결 안정성은 규칙만으로 끝나지 않고 아웃바운드 품질에 크게 좌우됩니다. 지연(latency)이 낮아 보여도 패킷 손실·재전송이 많으면 긴 작업·API 요청에서 체감이 크게 나빠집니다. fallback·url-test류 그룹으로 자동 전환을 두면 세션이 끊기는 빈도를 줄일 수 있습니다. 모든 트래픽을 한 노드에 몰기보다, Manus 관련 호스트만 프록시 그룹에 매핑하고 나머지는 기존 분할을 유지하는 편이 일상 트래픽에 미치는 부작용이 적습니다.
4DNS·FakeIP·직접 연결 선택
DNS가 상위 공유기·사내 리졸버를 한 번 더 거치면, FakeIP와 실제 응답이 엇갈려 규칙 매칭이 실패하는 경우가 있습니다. Meta 계열에서는 fake-ip-filter에 로컬·사내 이름을 넣고, 스니퍼(sniffer) 사용 시 도메인 복원이 기대와 다르면 DOMAIN 규칙이 빗나갈 수 있습니다. DoH·DoT로 상위까지 일관되게 맞추면 오탐·오매칭이 줄어드는 경우가 많습니다. 일부 결제·위치 검증 구간은 의도적으로 직접 연결이 안정적인 경우도 있으나, 범위를 좁혀 적용하지 않으면 다시 세션이 갈라질 수 있습니다. 구체적인 점검 표는 Meta 코어 DNS 유출 방지 가이드를 참고하세요.
요약: 분류 규칙은 클라이언트가 본 도메인과 DNS 경로가 같을 때 가장 잘 맞습니다. FakeIP·스니퍼·업스트림 DNS를 한 번에 바꾸지 말고 한 층씩 검증하세요.
5다른 글과의 역할 분담
ChatGPT·OpenAI·Claude·Gemini 글은 같은 프레임으로 호스트 수집·규칙·DNS 정합성을 반복합니다. 본문은 Manus의 공개 웹 도메인 명명을 출발점으로 동일 절차를 적용할 뿐입니다. 개발 도구 체인 전체(패키지 레지스트리 등)는 Cursor·GitHub·npm 글과 역할이 나뉩니다.
6검증: 규칙 적중 → DNS → 노드 로그
변경 후에는 한 번에 한 변수만 바꿉니다. 먼저 Clash 연결 로그에서 문제가 된 호스트가 어떤 정책 그룹·어떤 규칙 줄에 매칭됐는지 확인합니다. 그다음 같은 호스트에 대해 DNS 응답이 기대와 일치하는지(실 IP vs FakeIP)를 점검합니다. 마지막으로 TLS까지 시간을 재 보고, 다른 노드·다른 회선과 대조해 “규칙 문제인지 품질 문제인지”를 가릅니다. 시스템 프록시만 켠 상태와 TUN을 켠 상태를 번갈아 비교하면 “앱이 프록시를 모른다”는 가설을 빠르게 확인할 수 있습니다.
API 키·세션 토큰이 들어가는 요청은 로그·캡처에 남기지 않도록 주의하고, 실패 시 HTTP 상태 코드와 TLS 오류 메시지를 구분해 기록하면 원인 추적이 빨라집니다.
준수: 소속 기관·국가의 네트워크·데이터 규정을 준수하세요. API 키·로그는 외부에 노출하지 말고, 엔드포인트 예시는 공개 문서·본인 관측을 기준으로 하되 변경 가능성을 염두에 두세요.
마치며
Manus에 대한 관심이 클수록, 체감 품질은 에이전트 로직뿐 아니라 네트워크 경로에도 좌우됩니다. 웹 접속·작업 진행·API가 서로 다른 호스트·장시간 연결을 쓰는 이상, Clash의 분류 규칙과 DNS·FakeIP·필요 시 DoH를 같은 그림으로 맞추는 작업이 반복됩니다. 관측 가능한 호스트 목록과 최소 규칙 세트, 그리고 규칙 적중 → DNS → 노드 로그 순의 검증 루틴만 갖추어도 “웹만 되고 작업은 끊김”류 대응 시간은 크게 줄어듭니다.