Foundry 느림? Clash Azure AI 엔드포인트 분기(2026)

증상: 포털은 되는데 Playground·API만 끊길 때

2026년 4월, 마이크로소프트는 MAI-Image-2-Efficient 같은 신규 모델을 Microsoft Foundry와 MAI Playground 등 개발자·운영자가 바로 실험할 수 있는 경로에 올리며 공지했습니다. 모델 자체의 품질 논의와 별개로, 실무에서는 이런 물결이 동시에 몰립니다. Foundry 포털(ai.azure.com 계열)과 프로젝트 콘솔은 대체로 열리는데, 채팅·이미지 미리보기 스트림만 중간에 멈춘다. Azure OpenAI 리소스의 {리소스명}.openai.azure.com REST 호출만 간헐적으로 502·타임아웃처럼 보인다. Azure CLI나 SDK로 배포·키 조회는 되는데, 브라우저에서만 특정 호스트가 느리다. 로그인은 되는데 ARM 템플릿이나 리소스 목록 패널이 무한 로딩에 걸린다.

이런 패턴은 단순히 「해외 회선이 느리다」로만 설명되지 않는 경우가 많습니다. Azure AI 스택은 포털 UI, Entra ID 로그인, Resource Manager, 모델 추론 게이트웨이, 계측·텔레메트리를 서로 다른 호스트로 쪼개고, 짧은 시간에 다수의 TLS 연결을 동시에 엽니다. 그중 일부만 직접 연결로 새거나, 너무 넓은 DOMAIN-KEYWORD 규칙에 걸려 의도와 다른 출구로 나가면 체감상 「가끔만」 실패하는 것처럼 보입니다. 따라서 Clash Microsoft Foundry 및 Azure AI 프록시 관점에서, 관련 FQDN을 Foundry 분기 전용 프록시 그룹에 고정하고 연결 패널·DNS로 기대한 노드가 맞는지 확인하는 흐름이 필요합니다.

브랜드는 다르지만 Clash 측 원리는 ChatGPT·OpenAI API 분기, Gemini·Google AI 분기와 같습니다. 다만 마이크로소프트 쪽은 login.microsoftonline.com·management.azure.com처럼 비 AI 제품과 공유되는 호스트가 많아, 규칙을 한 번에 넓게 잡으면 부작용이 생기기 쉽습니다. 아래 호스트 목록은 출발점이며, 실제 프로젝트에서는 최근 연결 로그에 찍힌 FQDN을 기준으로 룰셋을 계속 다듬어야 합니다.

⚠️

준수 안내: 프록시 사용과 Azure·Microsoft 서비스 이용은 거주 지역 법령, 조직 정책, 마이크로소프트 이용약관 및 Azure 계약을 따라야 합니다. 본문은 네트워크 경로와 Clash 설정 기술만 다루며, 규제 회피나 약관 위반을 조장하지 않습니다.

묶을 호스트: Foundry 포털·ARM·추론 엔드포인트

실무에서 자주 등장하는 축을 나누어 생각하면 설정이 단순해집니다. 첫째, Foundry·AI Studio 계열 포털은 ai.azure.com을 중심으로 하며, 문서에 따라 클래식·신규 포털 경험이 나뉘어 있을 수 있습니다. 둘째, 구독·리소스 관리는 management.azure.com, portal.azure.com 등 ARM·포털 공통 호스트가 이어집니다. 셋째, 로그인·토큰은 login.microsoftonline.com, 넓게는 Entra ID가 쓰는 추가 호스트가 붙습니다. 넷째, Azure OpenAI 추론은 리소스마다 *.openai.azure.com 형태의 엔드포인트가 핵심이며, SDK·REST 예제가 이 호스트를 향합니다. 다섯째, 일부 Cognitive Services 계열은 *.cognitiveservices.azure.com 패턴을 쓰기도 합니다.

Azure AI 프록시를 설계할 때 흔한 실수는 DOMAIN-SUFFIX,azure.com처럼 지나치게 넓게 잡는 것입니다. 그러면 동일 구독의 가상 머신, 스토리지, 모니터링까지 같은 출구로 몰려 지연·비용·보안 정책 충돌이 생깁니다. 대신 DOMAIN,ai.azure.com, DOMAIN-SUFFIX,openai.azure.com, DOMAIN,login.microsoftonline.com처럼 연결 패널에서 반복 확인되는 이름부터 rule-providers YAML에 한 줄씩 쌓는 방식이 안전합니다. 팀과 공유할 때도 변경 이력을 남기기 좋습니다.

규칙 순서: GEOIP·거대 룰셋보다 앞에 둘 것

Foundry 분기에서 가장 흔한 실수는 규칙 순서입니다. GEOIP,CN,DIRECT나 거대한 RULE-SET이 *.azure.com을 먼저 직결이나 다른 그룹으로 내버리면, 아래에 정교한 규칙을 아무리 추가해도 도달하지 못합니다. 중국 본토 직결과 해외 프록시를 함께 쓰는 패턴은 규칙 분류 실무 글과 함께 읽으면 전체 그림이 잡힙니다. 구독 노드가 제대로 로드됐는지는 구독 가져오기에서 먼저 확인하세요.

전용 그룹 이름(예: AI-AZURE)을 규칙에 쓸 때는 YAML 전체에서 오타 없이 동일한 문자열인지 확인합니다. 존재하지 않는 그룹을 가리키면 프로필이 로드되지 않습니다. 또한 MATCH 직전까지 Foundry·Azure AI 관련 규칙이 올라와 있는지 한 번 더 훑는 습관이 안정적 접속에 도움이 됩니다.

TLS·SNI: 엔드포인트가 바뀌어 보이는 이유

Azure 측 게이트웨이는 SNI와 인증서 체인 조합이 엄격한 편입니다. 프록시 노드가 세션 중간에 바뀌거나, 일부 연결만 다른 지역으로 나가면 클라이언트는 「간헐 실패」로 인지합니다. Microsoft Foundry 웹 UI는 짧은 주기로 여러 하위 경로에 요청을 내므로, url-test 기반 자동 선택이 너무 공격적이면 체감이 더 나빠질 수 있습니다. 진단 단계에서는 select로 한 노드를 수동 고정해 재현성부터 확보하는 편이 좋습니다.

브라우저 개발자 도구의 네트워크 탭과 Clash 연결 로그를 나란히 놓고 보면, 실패한 요청의 호스트 이름이 어떤 규칙에 매칭됐는지 빠르게 좁힐 수 있습니다. TLS 핸드셰이크 단계에서 끊기면 DNS·노드 지연·SNI 중 어디를 의심할지 갈림목이 선명해집니다.

전략 그룹: 지연·세션·쿼터 사이에서 고르기

proxy-groups 설계는 사용 패턴에 맞춥니다. (1) select로 지금 쓸 회선을 고정해 재현 가능한 경로를 만든다. (2) 여러 노드를 둔다면 url-test는 간격을 너무 짧게 두지 않는다. (3) fallback은 장애 대비에 유용하지만, API 호출이 연쇄적으로 다른 노드로 튀면 서비스 측 rate limit과 겹쳐 오히려 불안정해질 수 있다. (4) 그룹 안에 DIRECT를 남겨 두면 비교 실험에는 좋지만, 「API만 불안정」이라는 신고만 있고 실제로는 직행이 섞인 경우를 가리기 어렵다.

Azure CLI·SDK: 시스템 프록시 밖으로 새는 트래픽

브라우저는 OS 프록시를 따르는데, 터미널의 az CLI나 Python SDK만 프록시를 타지 않으면 증상이 더 미묘해집니다. Mihomo 계열에서는 PROCESS-NAME 규칙으로 특정 실행 파일을 전용 그룹에 매핑할 수 있습니다. 운영체제마다 바이너리 이름이 다르므로, 연결 로그에 찍힌 이름을 기준으로 넣어야 합니다. 앱 전체를 코어에 넣고 싶다면 TUN 모드도 선택지입니다.

macOS·Linux 터미널에서는 HTTPS_PROXY 환경 변수를 맞추는 방식이 자주 쓰입니다. 흐름은 터미널·Homebrew 프록시 환경 변수 글과 짝을 이루도록 읽을 수 있습니다.

YAML 스케치(이름·FQDN은 실측으로 교체)

아래는 구조를 보여 주는 예시입니다. AI-AZURE, 멤버 프록시 이름, 호스트는 반드시 본인 프로필과 연결 로그에 맞게 바꿔야 합니다.

# Example only — replace group names and FQDNs with your profile and logs
proxy-groups:
  - name: AI-AZURE
    type: select
    proxies:
      - Proxy
      - AUTO
      - DIRECT

rules:
  - DOMAIN,ai.azure.com,AI-AZURE
  - DOMAIN-SUFFIX,openai.azure.com,AI-AZURE
  - DOMAIN,login.microsoftonline.com,AI-AZURE
  - DOMAIN,management.azure.com,AI-AZURE
  # Optional if logs show cognitive services hosts
  # - DOMAIN-SUFFIX,cognitiveservices.azure.com,AI-AZURE
  # Optional when CLI ignores system proxy (OS-specific process name)
  # - PROCESS-NAME,az,AI-AZURE
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

실제 환경에서는 portal.azure.com을 같은 그룹에 넣을지, 기본 프록시로 둘지 팀 정책에 따라 갈립니다. 로그인만 다른 출구로 나가면 토큰 발급이 끊기거나 리소스 목록이 비는 증상이 생길 수 있으니, 연결 패널로 한 번에 묶을 범위를 정하세요. *.azure.com 전체를 넓게 잡으면 비 AI 리소스까지 같이 움직이므로, 가능하면 로그에 찍힌 FQDN부터 좁히는 것이 안전합니다.

DNS·fake-ip: 숨은 간헐 실패

fake-ip 모드에서는 규칙 매칭은 빠르지만, 특정 호스트에서 해석·캐시가 어긋나면 클라이언트가 보기에도 「가끔만」 실패합니다. Azure 게이트웨이는 TLS와 SNI 조합이 민감한 편이라, DNS만 고쳤는데 규칙이 갑자기 맞아떨어지는 사례가 많습니다. 반복되는 호스트는 fake-ip-filter에 넣거나, nameserver와 fallback 체인을 재검토하세요. 절차는 Fake-IP·DNS 실측 가이드와 함께 보는 것이 좋습니다.

연결·DNS 자가 점검 절차

브라우저에서 Foundry 프로젝트를 열고 모델 카탈로그·Playground를 실제로 돌리며 최근 연결에 뜬 호스트를 메모합니다.
동일 시점에 az 또는 SDK로 짧은 추론 호출을 한 번 보내, openai.azure.com 계열이 어떤 규칙·그룹으로 잡히는지 비교합니다.
규칙 열에 기대한 그룹 이름(예: AI-AZURE)이 찍히는지, 다른 요청과 섞이지 않는지 확인합니다.
지연이 큰 노드로 바꿔 보고 오류 패턴이 따라오는지 봅니다. 변하지 않으면 규칙·DNS·인증 쪽을 우선 의심합니다.
기업 VPN·보안 에이전트와 경로가 겹치지 않는지 확인합니다.

보안·운영 메모

프록시 노드는 트래픽을 중계할 수 있으므로 신뢰할 수 있는 구독을 전제로 합니다. 회사 장비에서는 정책 위반이 될 수 있으니 사내 가이드를 우선합니다. API 키·연결 문자열은 클라이언트에 노출되지 않게 관리하고, 팀과 룰셋을 공유할 때는 변경 이력을 남기세요. Azure Portal의 사용량·쿼터 화면을 함께 보면 네트워크 문제와 서비스 측 제한을 구분하기 쉽습니다.

체크리스트

ai.azure.com·openai.azure.com 등 핵심 FQDN 규칙이 넓은 GEOIP·MATCH보다 앞에 있는가.
로그인·ARM·추론 호스트가 의도한 그룹으로 매칭되는가.
프록시 그룹 이름이 YAML 전체에서 일관되는가.
DNS 모드·fake-ip-filter가 최근 로그와 모순되지 않는가.
TUN·시스템 프록시·프로세스 규칙·터미널 환경 변수 중 무엇을 쓰는지 일치하는가.

정리

Microsoft Foundry와 Azure AI는 포털·인증·리소스 관리·추론 게이트웨이가 서로 다른 호스트로 퍼져 있습니다. Clash Microsoft Foundry 관점에서는 이를 도메인 분류로 한 프록시 그룹에 묶고, 필요하면 PROCESS-NAME으로 CLI까지 포함하며, TLS·DNS·연결 로그로 기대한 출구인지 검증하는 것이 핵심입니다. 「마이크로소프트 전체를 한 방에 빠르게」가 아니라, 실패한 요청의 FQDN을 기준으로 룰셋을 유지보수하는 방식이 장기적으로 가장 덜 깨집니다.

클라이언트를 최신 Mihomo 계열로 맞추는 일도 체감에 영향을 줍니다. 플랫폼별 패키지는 공식 다운로드 페이지에서 고를 수 있습니다. 기본 개념은 문서 섹션과 함께 보시면 설정 속도가 빨라집니다. → Clash를 무료로 내려받아 규칙을 적용한 뒤, 브라우저와 터미널에서 Foundry·Azure OpenAI 호출을 다시 시험해 보세요.