Discord·Midjourney가 동시에 「맴도는」 이유

Midjourney를 쓰려면 Discord 앱이나 웹, 초대 링크, 봇 상호작용, 이미지 미리보기까지 한 화면처럼 보여도 실제로는 여러 호스트가 동시에 움직입니다. Discord 쪽은 웹소켓·REST API·미디어 CDN·초대·인증이 각각 다른 이름으로 갈라지고, Midjourney 공식 사이트·결제·문서·상태 페이지 같은 트래픽은 또 다른 접미사로 이어질 수 있습니다. 「로딩만 돈다」「로그인 화면에서 멈춘다」는 말은 대개 일부 연결만 성공한 채 세션이 완성되지 않은 상태를 뜻합니다.

여기에 전역 프록시를 얹으면 무관한 대용량 트래픽까지 같은 노드로 몰려 지연·버퍼·타임아웃이 겹칩니다. Discord 음성·화면 공유·대용량 첨부와 무관한 탭까지 한 출구를 쓰면, 겉으로는 「노드가 나빠졌다」처럼 보이지만 실제로는 대역과 큐잉 문제인 경우가 많습니다. Clash는 연결마다 DIRECT인지 특정 정책 그룹인지 정하므로, ChatGPT 전용 글에서 다룬 것처럼 도메인 단위 분류가 여기서도 핵심입니다. 다만 대화형 AI 한 탭과 달리 항상 켜 두는 소셜 클라이언트가 같이 있어 설계 포인트가 조금 다릅니다.

이 글은 일반적인 「우회」 안내가 아니라 허용된 네트워크에서 규칙 세트·정책 그룹·DNS를 맞추는 이야기입니다. 서비스 이용이 금지된 환경이라면 여기서 멈추세요.

ℹ 관측 팁: 실패 순간의 호스트 이름을 모으세요. Discord는 discord.com, discordapp.com, discord.gg, CDN 계열 호스트가 자주 보이고, Midjourney는 midjourney.com 트리와 제휴 결제·정적 자산 호스트가 섞입니다. 로그에 잡히는 정책 이름과 목록을 대조하면 「규칙 구멍」인지 「노드 한계」인지 빨리 갈립니다.

핵심: 창작·채팅 스택만 전용 출구, 나머지는 직접

실무적으로는 Discord + Midjourney 묶음을 하나의 논리 그룹으로 보고, 여기에만 안정적인 HTTPS 출구를 붙이는 방식이 재현성이 좋습니다. 일상 웹·국내 서비스·게임 업데이트는 DIRECT나 별도 저지연 그룹에 두면, 전역 프록시와의 대역 경쟁을 줄일 수 있습니다. 정책 그룹 이름은 예를 들어 MJ_DISCORD처럼 짧고 고유하게 짓고, rules에서 해당 접미사 줄들이 그 이름을 가리키게 맞춥니다.

구독에 포함된 geosite·제3자 규칙 세트에 Discord 분류가 있을 수 있지만, 버전과 공급자에 따라 범위가 달라집니다. 자동 목록만 믿지 말고, 클라이언트 연결 로그에 실제로 뜨는 호스트를 몇 번이라도 확인해 DOMAIN-SUFFIX를 보강하세요. 규칙 파일을 읽기 쉽게 유지하는 방법은 규칙 분류 모범 사례를 참고하면 좋습니다.

여러 기기에서 같은 계정을 쓸 때 경로가 제각각이면 「한 PC만 로그인이 풀린다」처럼 보이기도 합니다. 프로필을 통일하거나 기기별로 의도를 문서화해 두세요. GUI와 로그 표현이 다른 경우가 있어, 코어 YAML을 가끔 직접 보는 습관이 장기적으로 유리합니다. 클라이언트 선택은 클라이언트 고르기에서 정리한 기준을 함께 보시면 됩니다.

DOMAIN-SUFFIX·게이트웨이·CDN·규칙 세트

DOMAIN-SUFFIX,discord.com,MJ_DISCORD 형태는 해당 접미사로 끝나는 이름을 한 번에 지정합니다. Discord 생태계에서는 초대·게이트웨이·API·미디어가 서로 다른 서브도메인으로 나뉘므로 접미사 규칙이 기본 축이 됩니다. 단일 호스트만 필요하면 DOMAIN을 쓰고, DOMAIN-KEYWORD는 범위가 넓어 오탐이 나기 쉬워 실측 후 최후 수단으로 두는 편이 안전합니다.

아래 YAML은 예시입니다. 실제 환경의 구독 이름·지역 정책·내부망 예외에 맞게 바꿔야 하며, 누락된 CDN 호스트가 있으면 로그를 보고 줄을 추가합니다.

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,discord.com,MJ_DISCORD
  - DOMAIN-SUFFIX,discordapp.com,MJ_DISCORD
  - DOMAIN-SUFFIX,discord.gg,MJ_DISCORD
  - DOMAIN-SUFFIX,discordapp.net,MJ_DISCORD
  - DOMAIN-SUFFIX,discord.media,MJ_DISCORD
  - DOMAIN-SUFFIX,midjourney.com,MJ_DISCORD
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

cdn.discordapp.com은 discordapp.com 접미사로 함께 잡히는 경우가 많고, 미디어 전용으로 discordapp.net이 보이기도 합니다. 엔드포인트가 바뀌면 한 번 맞춰 둔 프로필이 몇 달 뒤 스피너를 보일 수 있으니, 먼저 새 호스트가 규칙에 없는지 의심하세요. 규칙 공급자를 쓸 때는 Discord 관련 파트가 다른 광범위 규칙에 묻히지 않게 순서를 조정합니다.

DNS·fake-ip와 로그인 스피너

DNS 응답이 왜곡되거나 캐시가 꼬이면, 브라우저는 빨리 그려진 뒤 TLS 단계에서 멈춘 것처럼 보입니다. fake-ip 모드를 쓸 때는 도메인 규칙과 해석 경로가 어긋나면 「이름은 나왔는데 연결이 안 이어진다」는 패턴이 납니다. 브라우저 DoH, OS 리졸버, Clash DNS, 다른 VPN을 동시에 겹치면 우선순위가 꼬이기 쉬우므로, FAQ에서 DNS·연결성 흐름을 한 번 정리해 두는 것이 좋습니다.

Discord 로그인은 OAuth·쿠키·리다이렉트가 여러 도메인을 오갑니다. 그중 하나만 다른 출구를 타면 로그인 스피너가 길어질 수 있습니다. 실패 URL의 호스트를 기록해 규칙에 반영하세요. 기업 프록시나 SSL 검사가 끼어 있으면 증상이 비슷해 보이므로, 동일 증상이라도 원인은 네트워크 정책일 수 있습니다.

규칙 순서·광범위 포획·MATCH

규칙은 위에서 아래로 적용되며 먼저 맞은 줄이 승리합니다. 지나치게 넓은 DOMAIN-KEYWORD나 거대한 제3자 세트가 Discord·Midjourney용 구체 규칙보다 위에 있으면, 의도와 다른 출구로 밀려납니다. 광고 차단 목록이 CDN을 오탐으로 막는 경우도 있어, 증상이 갑자기 생기면 최근에 바뀐 규칙 공급자를 의심하세요.

MATCH는 나머지 전부에 대한 기본값입니다. MATCH,DIRECT를 쓰는 전제에서 새 CDN 호스트가 빠지면 해당 트래픽만 직접 경로에 남아 불안정해질 수 있습니다. 장기적으로는 전역으로 모든 것을 프록시에 넣기보다, 필요한 접미사를 계속 보강하는 편이 대역과 계정 세션 모두에 유리합니다.

디스코드 앱·브라우저·TUN

Discord 데스크톱 앱은 시스템 프록시를 따르지 않는 경우가 있습니다. 그때는 TUN 모드로 시스템 라우팅에 올려 앱 트래픽까지 같은 규칙을 타게 하는 방법이 흔합니다. Electron 계열 앱과 방화벽·다른 VPN의 상호작용은 환경마다 달라, 적용 전 TUN 심화에서 주의점을 확인하세요.

브라우저만 쓸 때는 OS 프록시로 충분한 경우도 많습니다. 어느 쪽이든 검증은 동일합니다. 라이브 연결 목록에서 Discord·Midjourney 관련 목적지가 기대한 정책 그룹을 타는지 확인하세요. 앱만 실패하고 브라우저만 성공하면 커버리지나 모드 선택 문제일 가능성이 큽니다.

구독·원격 규칙 갱신 루프

구독 URL과 원격 규칙 세트 다운로드가 실패하면 프로필이 낡고 새 호스트 대응이 늦어집니다. 갱신 트래픽은 DIRECT 등 안정 경로로 빼 두는 패턴이 안전합니다. 운영 습관은 구독·노드 유지보수를 함께 보면 정리하기 쉽습니다.

어제까지 되던 것이 오늘 아침부터 스피너라면, 노드 품질만 의심하지 말고 규칙 갱신 실패와 TLS·timeout을 분리해 보세요. timeout·TLS 로그 해석이 단계 나누기에 도움이 됩니다.

⚠ 준수: 현지 법령·Discord·Midjourney 약관·고용주·학교의 네트워크 정책을 지키세요. 본문은 허용된 환경에서 Clash 설정을 이해하기 위한 기술 설명이며, 무단 접근·보안 회피·타인에게 피해를 주는 트래픽 조작을 조장하지 않습니다.

준수를 고려한 자가 점검

아래 순서는 토글을 무작정 바꾸기 전에 범위를 좁히는 데 도움이 됩니다.

  1. 이 네트워크에서 Discord·Midjourney·Clash 사용이 허용되는지 확인합니다.
  2. 스피너·로그인 실패 시점의 호스트 이름을 수집합니다.
  3. Clash 로그에서 해당 연결이 MJ_DISCORD(또는 동등 그룹)를 타는지 확인합니다.
  4. DOMAIN-SUFFIX와 규칙 세트를 보강하고, 광범위 규칙과의 순서를 점검합니다.
  5. DNS·fake-ip·DoH 중첩을 정리하고 FAQ 흐름과 맞춥니다.
  6. 데스크톱 앱이면 TUN과 시스템 프록시를 비교합니다.
  7. 구독·원격 규칙 갱신이 막히지 않았는지 확인합니다.
  8. 로컬 요인을 줄인 뒤에만 노드 교체나 공식 상태 페이지를 참고합니다.

각 단계에서 무엇이 바뀌었는지 짧게 메모하면 같은 증상이 다시 와도 빠르게 되돌아갈 수 있습니다.

맺음말: 대화형 AI 글과 다른 한 세트

ChatGPT·Claude류 글은 주로 단일 웹앱의 API·정적 자산 분할을 다룹니다. Midjourney는 Discord라는 항상 켜진 클라이언트와 함께 쓰이는 경우가 많아, 전역 프록시와의 상호작용이 더 자주 드러납니다. Clash로 이름 공간을 쪼개 두면 대역을 덜 잡아먹고, 로그인·이미지 생성·채널 동기화가 한 출구에서 무너지는 패턴을 줄일 수 있습니다.

해법은 또 하나의 「모든 트래픽 ON」 스위치가 아니라, Discord·Midjourney 관련 접미사를 명시하고 DNS를 같은 체계로 맞추며, 규칙 세트를 주기적으로 신선하게 유지하는 것입니다. 투명한 로그와 편집 가능한 프로필이 있는 클라이언트일수록 그 과정이 짧아집니다.

검은 상자형 도구보다 규칙이 파일에 남는 Clash 쪽이, 자주 바뀌는 CDN과 엔드포인트를 대응하기에 유리합니다. 한 번 경로를 문서화해 두면 다음 업데이트 때도 훨씬 덜 지칩니다.

→ Clash를 무료로 다운로드하고, Discord·Midjourney용 정책 그룹과 규칙 세트를 프로필 안에서 정리해 보세요.