ComfyUI "Failed to Fetch": 어떤 연결이 실패했는지 찾기

Failed to fetch만으로는 ComfyUI의 실제 원인을 알 수 없습니다.

이 문구는 브라우저가 요청을 보냈지만 사용할 수 있는 응답을 받지 못했다는 뜻입니다. 실패한 요청은 ComfyUI 자체, ComfyUI Manager, ComfyRegistry, workflow draft 저장, server logs 또는 WebSocket 연결일 수 있습니다.

바로 ComfyUI를 재설치하지 마세요.

먼저 UI가 무엇을 가져오려다 실패했는지 확인해야 합니다.

올바른 분기 선택

먼저 backend가 살아 있는지 확인

ComfyUI를 시작한 terminal, PowerShell 창, command prompt, launcher log 또는 Desktop log를 확인합니다.

정상 backend는 계속 실행 중이며 frontend가 사용할 주소를 보여주는 경우가 많습니다.

예:

To see the GUI go to: http://127.0.0.1:8188

자신의 로그에 표시된 host와 port 를 사용하세요. 모든 설치가 port 8188을 쓰는 것은 아닙니다.

backend가 아직 실행 중일 가능성이 높은 경우

• terminal이 닫히지 않았습니다.
• 로그 끝에 traceback이 없습니다.
• 로그에 표시된 주소로 ComfyUI가 열립니다.
• Queue와 History request가 아직 동작합니다.
• Manager 또는 frontend의 한 기능만 실패합니다.

이 경우 문제는 특정 request, browser path, network layer 또는 extension에 한정될 가능성이 높습니다.

backend가 멈췄을 수 있는 경우

• terminal이 닫혔습니다.
• fetch error 직전에 Python traceback이 표시되었습니다.
• 원래 주소가 더 이상 열리지 않습니다.
• UI 전체가 동시에 실패합니다.
• 재시작 후 다른 port를 사용합니다.

브라우저의 Failed to fetch는 backend가 왜 멈췄는지 설명하지 못합니다. 마지막 terminal error를 읽고, server가 시작되지 않는다면 ComfyUI Startup Failed를 사용하세요.

server logs만 로드되지 않는 경우

메인 ComfyUI UI는 동작하지만 server-log panel만 Failed to fetch를 표시한다면 전체 ComfyUI 장애가 아닐 수 있습니다.

가능한 원인:

• server-log endpoint;
• frontend/backend version mismatch;
• 오래된 browser bundle;
• endpoint를 전달하지 않는 reverse proxy;
• 다른 backend route를 쓰는 Desktop 또는 packaged environment.

ComfyUI "Failed to Fetch Server Logs"로 이동하세요. 이 부모 페이지에서는 endpoint별 세부 절차를 반복하지 않습니다.

Manager가 custom-node list를 로드하지 못하는 경우

Manager 실패가 곧 ComfyUI 전체 고장을 의미하지는 않습니다.

ComfyUI Manager는 다음에 접근해야 할 수 있습니다.

• ComfyRegistry;
• GitHub;
• raw GitHub content;
• cached node list;
• Manager-specific API endpoints.

일반 ComfyUI generation이 아직 동작하는지 확인하세요.

Manager만 다음 메시지를 표시한다면:

Failed to get custom node list

또는:

Failed to find the following ComfyRegistry list

ComfyUI-Manager "Failed to Get Custom Node List"로 이동합니다.

Manager request 자체를 확인하기 전에 모든 custom node를 다시 설치하지 마세요.

UI가 계속 Reconnecting을 표시하는 경우

Reconnecting은 보통 frontend가 ComfyUI backend와의 live connection을 잃었다는 뜻입니다.

이는 선택적인 Manager request 하나가 실패한 것과 다릅니다.

가능한 영역:

• ComfyUI process 중지;
• backend 재시작;
• WebSocket connection 차단;
• reverse proxy가 WebSocket traffic을 전달하지 않음;
• browser가 오래된 port를 사용;
• PC 절전 또는 network 변경.

ComfyUI Reconnecting Error로 이동하세요.

페이지가 다시 연결되고 generation이 동작한다면 전체 dependency reinstall을 하지 마세요.

workflow draft 저장이 실패하는 경우

workflow draft 오류는 더 급합니다. 현재 graph가 열린 browser tab에만 남아 있을 수 있습니다.

가장 안전한 첫 행동은 tab을 새로고침하거나 닫기 전에 현재 가능한 Save 또는 Export 옵션을 사용하는 것입니다.

이 오류는 automatic draft-save request가 실패했다는 뜻입니다. workflow가 이미 사라졌다는 뜻은 아닙니다.

저장 또는 export하기 전에는 다음을 피하세요.

• 페이지 새로고침;
• browser tab 닫기;
• browser site data 삭제;
• 보이는 graph를 보존하지 않고 ComfyUI 재시작.

ComfyUI "Failed to Save Workflow Draft"로 이동하세요.

일반 workflow backup과 recovery는, 활성 오류가 아니라면 현재 같은 페이지의 workflow 저장 섹션을 참고하세요.

VPN, proxy, firewall 또는 회사 네트워크가 관련된 경우

메인 ComfyUI 페이지는 열리지만 다른 endpoint만 차단될 수 있습니다.

자주 발생하는 상황:

• ComfyUI를 reverse proxy로 접속함;
• browser proxy extension 활성화;
• VPN이 local routing을 변경함;
• security software가 localhost traffic을 필터링함;
• 회사 네트워크가 GitHub 또는 Registry request를 차단함;
• HTTP와 HTTPS가 섞임;
• WebSocket forwarding이 없음.

처음부터 모든 보안 설정을 끄지 마세요.

대신 비교하세요.

1. VPN 또는 proxy를 일시적으로 우회한 같은 동작
2. 메인 ComfyUI 페이지와 실패하는 특정 feature
3. local access와 reverse-proxy access
4. 일반 browser window와 extension-free private window

어떤 network layer를 우회했을 때만 문제가 사라진다면, ComfyUI Python 환경이 아니라 그 layer의 rule을 확인하세요.

ComfyUI Desktop을 사용하는 경우

ComfyUI Desktop은 manual 또는 Portable 설치와 startup environment 관리 방식이 다릅니다.

다음을 가정하지 마세요.

• backend가 항상 default port를 사용함;
• Python environment가 system Python과 같음;
• Portable repair command가 Desktop에도 적용됨;
• restart 후 browser address가 그대로임.

Desktop app 또는 log에서 다음을 확인하세요.

• active backend address;
• startup failure messages;
• frontend/backend version information;
• backend restarted 여부;
• extension loading errors.

Desktop 관리 path와 recovery action은 release마다 달라질 수 있습니다. manual 또는 Portable용 command를 적용하기 전에 현재 app UI 또는 공식 Desktop documentation을 확인하세요.

browser developer tools로 실패한 request 찾기

메시지가 너무 애매하면 browser가 어떤 request가 실패했는지 보여줄 수 있습니다.

Chromium 기반 browser에서는:

1. Developer Tools를 엽니다.
2. Network를 선택합니다.
3. Failed to fetch를 발생시키는 동작을 다시 수행합니다.
4. 실패한 request를 찾습니다.
5. request name, URL, status, error를 기록합니다.

Network panel screenshot을 공유할 때 cookies, authorization headers, private workflow data, local username, API key를 공개하지 마세요.

먼저 하지 말아야 할 것

다음을 universal fix로 사용하지 마세요.

• ComfyUI 재설치;
• 모든 custom node 삭제;
• 모든 Python package upgrade;
• system Python에서 pip install 실행;
• workflow를 export하기 전 browser data 삭제;
• firewall 영구 비활성화;
• HTTP request 하나가 실패했다는 이유로 CUDA 또는 PyTorch 변경;
• 모든 설치가 port 8188을 쓴다고 가정.

이런 조치는 실패한 request를 식별하지 못한 채 두 번째 문제를 만들 수 있습니다.

문제가 해결되었는지 확인

처음 Failed to fetch가 발생했던 정확한 동작을 다시 수행합니다.

성공 조건:

• 같은 panel이 로드됨;
• Manager가 list를 가져옴;
• 페이지가 reconnecting을 멈춤;
• workflow draft가 저장됨;
• failed request가 usable response를 반환함;
• ComfyUI가 startup log의 address에서 계속 열림.

원래 실패가 특정 Manager, log, draft, WebSocket request였다면 "페이지가 한 번 열렸다"만으로 통과 처리하지 마세요.

Wonderful Launcher가 도움이 되는 경우

Wonderful Launcher는 어떤 layer가 실패했는지 확인한 뒤 가장 유용합니다. ComfyUI environment, model folder, custom node setup을 더 정리된 상태로 유지하면 모든 connection message를 full reinstall로 취급하지 않아도 됩니다.

실패한 request가 missing models, broken custom nodes, damaged local environment를 가리킨다면 위의 구체적인 guide를 먼저 사용하고, recovery 작업을 더 깔끔하게 관리하고 싶을 때 Wonderful Launcher 다운로드를 사용하세요.

관련 ComfyUI 연결 오류

• Failed to Fetch Server Logs
• Failed to Get Custom Node List
• ComfyUI Reconnecting Error
• Failed to Save Workflow Draft
• ComfyUI Startup Failed
• ComfyUI Workflow Has Missing Nodes

출처 참조

• Official ComfyUI troubleshooting overview
• Official custom node troubleshooting guide
• Official ComfyUI Manager pack management guide