미드저니 웹 스피너? Clash midjourney.com 분류·노드·CDN

1. 전형적인 증상: “화면은 열리는데 생성만 안 된다”

Midjourney 웹 클라우드에서는 계정 로그인, 갤러리·히스토리, 설정 패널처럼 HTML 위주 영역은 비교적 잘 보이는데, 프롬프트 제출 후 상태 표시줄이 무한 회전하거나, % 진행 없이 시간만 흘러간 뒤 타임아웃에 가까워지는 경우가 있습니다. 또는 썸네일·메타 정보는 뜨는데 결과물 이미지 URL이 비어 있거나 불러오기에 실패하는 패턴은 이미지·객체 저장소 CDN이 DIRECT이거나 다른 노드로만 나가는 경우에 흔합니다. Clash를 Rule 모드로 쓸 때는 DOMAIN-SUFFIX,midjourney.com 한 줄만으로는 부족할 수 있습니다.

챗봇형 LLM과 달리 이미지 생성 워크플로는 짧은 업로드, 장시간 백그라운드 작업 폴링, 고해상도 이미지 다운로드가 한 세션에 묶입니다. 따라서 같은 “해외”라도 호스트별로 회선 특성에 따른 차이가 생기며, 규칙이 갈라지면 스피너만 보이거나 중간부터 실패한 것처럼 느껴질 수 있습니다. “언젠가는 되겠지”처럼 모든 트래픽을 하나의 매우 느린 노드에 두는 것보다, 관련 호스트 세트를 맞추고 노드 후보만 바꿔 테스트하는 편이 원인 규명이 빠릅니다.

2. 웹·이미지·API·CDN이 한 번에 갈라질 수 있다

현대적인 SaaS 이미지 클라우드는 프런트 JS 번들, REST·GraphQL·WebSocket 상태 스트림, 생성된 자산(blob)이 각각 상이한 서브도메인이나 타사 CDN 엣지에서 서빙되는 구조가 많습니다. 인증(IdP)·결제 포털·고객지원 트래킹 같은 곳까지 겹치면 로그 하나를 기준으로 규칙을 짜야 합니다. 분류 규칙의 실무 목적은 사용자가 생성 제출부터 결과 확인까지 진행되는 동안, 그에 관련된 요청들이 가능한 한 동일 출구와 DNS 행렬에서 처리되도록 맞추는 것입니다.

브랜드 호스트: midjourney.com, www.midjourney.com 등—리다이렉트 체인이 있으면 처음 받는 최종 이름을 기준으로 정리합니다.
실제 작업·상태 확인: app, api 류 서브도메인(표기는 시점에 따라 변경될 수 있음)—Network 탭에서 실측 호스트를 잡습니다.
이미지 배포 네임: cloudfront.net, fastly, storage.googleapis.com 등—범 CDN 전역을 MJ 전용에 넣지 말고, 해당 연결이 현재 Midjourney 탭에서 발생했을 때만 규칙에 추가하는 방식을 권합니다. YouTube·googlevideo 글처럼 범 CDN 전체 규칙은 과매칭 위험이 큽니다.
DNS·fake-ip: fake-ip 모드에서는 fake-ip-filter 목록 정합을 맞춰야 합니다—fake-ip 점검 글을 참고하세요.

팁: 크롬·엣지 개발자 도구 Network에서 「Fetch/XHR」과 「Img」 필터를 나누어 생성 전후 시간대에 어떤 호스트가 붙는지 캡처한 다음, 규칙은 복붙 가능한 순서대로 목록화하면 이후 수정이 빨라집니다.

3. Midjourney 관련 도메인 맵(시작점)

서비스는 업데이트에 따라 호스트 이름이 바뀔 수 있어 아래는 2026년 기준 시작용 체크리스트입니다. 적용 전에는 꼭 본인 브라우저 로그와 대조해야 합니다. 공커 규모의 커뮤니티 룰이 있더라도, 가입 방식과 리전 플래그에 따라 접속 패턴은 사용자마다 조금씩 다릅니다.

핵심 브랜드: midjourney.com 계열 접미사 규칙을 기본 블록으로 두고, 규칙 순서에서 더 구체적인 하위 접미사가 먼저 오게 정합니다.
외부 에셋: 썸네일·워터마크·공유 카드 같은 정적 에셋이 CDN 공유 네임이라면 해당 호스트 줄을 같은 정책 그룹에 넣거나, 부작용 없이 테스트할 수 있도록 별도 테스트 프로필에서 먼저 검증합니다.
긴 재생·다운로드: 다운스케일·업스케일 반복에서는 동일 회선에서 MTU 또는 중간 패킷 드랍이 체감될 수 있으므로 다른 Wi-Fi·LTE에서도 같은지 비교하면 좋습니다.

Suno가 음성 미디어, Sora가 OpenAI 비디오 클라우드, Character.AI가 대화 렌더에 초점이라면 Midjourney는 이미지 패치·변형까지 포함한 무거운 정적 결과물이 중심입니다. 따라서 같은 “AI 규칙 한 덩어리”로 처리하기 어렵고, 도메인 맵도 이미지·스트리밍급 과매칭 가능성만큼 신중해야 합니다.

4. Clash 분류: Midjourney 전용 정책 그룹

아래 예시 YAML은 개념을 보여 줄 초안입니다. rules 상단쪽에 두어 넓은 GEOSITE·MATCH보다 먼저 매칭되게 하세요. 플레이스홀더 노드 이름·구독 구조는 사용자 환경에 맞게 바꿉니다. 인증 제공자 별 호스트가 붙었다면 과매칭이 걱정될 경우 직접 캡처한 정확한 서브도메인만 넣거나, 테스트 기간에는 IdP를 동일 그룹에 포함시키는 선택지도 있습니다.

# Example: Midjourney + related hosts — verify with DevTools/network logs
proxy-groups:
  - name: "Midjourney-Group"
    type: select
    proxies:
      - "US-LowLatency-1"
      - "EU-Stable-1"
      - "JP-Stable-1"
      - "DIRECT"
      - "FALLBACK"

rules:
  - DOMAIN-SUFFIX,midjourney.com,Midjourney-Group
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

실무에서는 초안 줄을 그대로 두지 않고 NETWORK 로그에 보인 실제 접미사만큼 줄을 더합니다. MATCH까지 기본 PROXY만 남아 있어도, 그 위쪽에서 다른 AI·스트리밍용 넓은 키워드 규칙에 먼저 걸려 의도하지 않은 출구로 가는 문제가 많으니 순서 검토를 잊지 마세요. 브라우저 탭 간에 다른 지역 노드를 바꿔 로그인을 반복했다면 세션 무결성 때문에도 스피너처럼 보일 수 있습니다. Windows에서는 데스크톱 앱 또는 PWA를 쓸 때 시스템 프록시 우회 가능성까지 점검합니다.

주의: 학교·회사 SSL 가시화·DNS 필터 또는 모바일 Private DNS는 Clash 정책과 별도로 간섭하여 동일 증상을 만들 수 있습니다. 동일 디바이스에서 Wi-Fi와 데이터망을 바꿔 비교하면 단서가 됩니다.

5. 노드 선택과 url-test 간격

이미지 생성 작업은 LLM 채팅보다 세션 시간이 길고, 상태 폴링이 포함될 경우 짧은 주기 자동 교체(url-test)가 들어 있는 그룹이면 중간에 접근 토큰·연결 상태가 깨져 무한 회전처럼 보이기도 합니다. Midjourney를 쓰는 동안에는 interval·tolerance 여유 범위를 넓히거나, 필요 시 select로 수동 고정해 비교해 보세요. 회선 선택에서 “표시되는 ping이 가장 낮은 노드”가 항상 무손실을 의미하지는 않습니다.

노드 후보 평가에 쓸 실무 순서

패킷 손실·지터: 낮은 레이턴시지만 손실이 있으면 다운스트림처럼 “멈춤”처럼 느껴질 수 있습니다.
IP 안정성: 같은 계정이라도 접속 순간 노드가 교체되면 일부 플래그가 새로 깔릴 수 있습니다.
전용 브라우저 프로필: 테스트 시 다른 생산성 SaaS 탭과 프록시 정책을 섞지 않으면 로그 분석이 쉬워집니다.

한 번에 많은 속성 탭을 여는 습관이 있으면, 중간 규모의 웹앱이 WebSocket 채널을 여러 개 동시 유지해 간헐히 지연을 높입니다. 테스트 중에는 해당 탭만 남겨 결과를 비교해 보세요.

6. 여전히 스피너일 때의 점검 순서

TUN 대 시스템 프록시: Electron·PWA는 시스템 설정을 따라가지 않을 수 있습니다. 회사 디바이스 정책과 충돌 여부까지 확인합니다.
IPv6 우회: IPv4 프록시·IPv6 직행 혼합이 되면 브라우저가 선택한 경로별로 속도 차가 큽니다. IPv6를 잠시 비활성화해 테스트하는 방법도 진단 단계에서는 유용합니다.
TLS·SNI: 간헐적 손글씨 TLS 실패 로그가 남으면 노드·SNI 진단 글을 순서대로 따라가 보세요.
규칙 역전·중복 매칭: 새로 줄을 추가했다면 해당 줄이 규제형 막판 키워드 규칙보다 확실히 앞쪽에 있습니다.

그래도 해결 어렵다면 Network 탭 캡처를 스크린샷·HAR로 남긴 채 호스트 순서 재정렬→노두 후보 2개만 순차 비교→DNS만 바꿔 테스트 순서로 좁히는 것이 속도 빠르고 회선 낭비가 적습니다. 운영자가 허용한 범위 내에서 테스트하는 한, 위 방법은 과도하게 공격적인 시도 없이 증명 가능한 순서입니다.

7. Suno·Sora·Character.AI와 무엇이 다른가

“AI 규칙”이라지만 실제 패킷 모양과 실패 패턴은 제품별로 많이 다릅니다. 같은 ChatGPT 레벨 블록을 다른 이미지·음악 클라우드에 그대로 옮길 필요는 없습니다.

구분	Suno	OpenAI Sora	Character.AI	Midjourney
핵심 콘텐츠	오디오 렌더·파일 배포	영상 버퍼링·CDN	실시간 대화·SSE	대형 이미지 정적 결과
실패 패턴	내보내기·플레이어만 끊김	동영상만 로딩	챗 스크롤 무한 회전	프롬프트 후 회전 또는 이미지만 비움
규칙상 주안점	오디오·스토리지 동시 일치	OpenAI 호스트 번들	character.ai 접미사·SSE	CDN·브랜드 호스트 균형 과매칭 방지

따라서 기존에 잘 만들어 두었던 한 범용 AI 정책 그룹 안에 새 이미지 전용 줄을 하나 추가하는 방법도 있지만, 운영·문제 발생 시 패턴을 놓치지 않으려면 별도 이름의 조합을 유지할 가치가 있습니다. 지금 작성한 Midjourney 전용 규칙 줄은 나중에 비슷한 이미지 서비스에도 줄 단위 참고 가능성이 높지만, 과매칭이 없도록 접미사는 실측부터라는 규칙을 지키세요.

8. 점검 체크리스트

현상	우선 확인
헤더·메뉴만 되고 생성 줄만 회전	상태 확인용 API 호스트 전부가 동일 그룹인지, 순서 역전 여부.
다른 탭에서는 되는 같은 날 같은 노드 불능	브라우저 확장 프로그램·스크립트 차단 또는 시크릿 모드 교차 테스트.
저녁에만 간헐	혼잡 노드 교체 간격 줄이고 수동 선택으로 교차 확인.
CORS·이미지만 차단	범 CDN 규칙을 넣었으면 다른 사이트가 함께 깨져 있는지 교차 검증 후 축소.

9. 요약

Midjourney처럼 브랜드 사이트, 상태 확인·작업 처리, 이미지 자산 분배가 겹치는 클라우드는 Clash 분류 규칙으로 관련 접미사를 한 정책 그룹에 모으고, 지터가 적은 안정 노드를 고르는 과정 단계별로 디버깅하는 것이 “스피너만 빙글빙글” 속성을 줄이는 가장 검증 가능한 순서입니다. Suno·Sora 글처럼 패킷 패턴별로 도메인 맵 설계 원칙이 다르므로 블루프린트를 그대로 복사하기보다, 본 글처럼 카테고리별 정책 그룹을 만드세요. 추가로 fake-ip 필터링, FALLBACK 과도 사용, RULE 매칭 역전을 일으키는 큰 접두사 패키지 같은 주변 변수를 점차적으로 제거했을 때 상태가 명확해집니다.

다른 범용 툴보다 도메인·정책 그룹에 대한 가시성이 높은 Clash는 이미지 클래스 트래픽을 테스트하기에 특히 적합합니다. 브라우저 개발 도구 로그 하나를 시작점으로 규칙을 덧붙이고, 테스트마다 줄 수를 과감하게 줄였다 넓혔다 반복하면 2026년 이후 새로워질 접미사에도 따라가기 쉬워집니다.

→ 지금 Clash를 무료로 내려받아 Midjourney용 규칙 세트를 시험해 보세요