Suno와 같은 음악 생성 API에서는 태스크(Task)가 succeeded 상태가 되더라도, 최종 파일을 즉시 가져올 수 있다는 보장이 없습니다. 이번 실측에서는 공개된 /content URL은 404/502 에러가 발생했지만, 상류(Upstream)의 audio_url은 정상적으로 다운로드할 수 있었습니다.

대상 태스크:

task_ac90b23619334516

폴링(Polling) 결과:

{
"status": "succeeded",
"format": "mp4",
...

공개 content URL 검증:

HEAD crazyrouter.com content URL: HTTP 404
HEAD api.crazyrouter.com content URL + Authorization: HTTP 404
GET api.crazyrouter.com content URL + Authorization: HTTP 502

이 시점만 보면 "생성 결과 다운로드를 사용할 수 없다"라고 판단하기 쉽습니다. 하지만 관리 측의 태스크 상세 정보에는 상류의 실제 미디어 URL이 포함되어 있었습니다.

data.data.resultJson.data[0].audio_url
data.data.resultJson.data[0].image_url

audio_url 검증 결과:

HEAD audio_url: HTTP 200, Content-Type: audio/mp3
GET audio_url: HTTP 200, Content-Type: audio/mp3, 412326 bytes

항목	결과
태스크 전송	성공
태스크 폴링 (Polling)	성공, succeeded
공개 /v1/videos/{task_id}/content	실패, 404/502
상류 resultJson.data[0].audio_url	성공, MP3 취득
실용 가능 여부	생성 결과는 가용함. 단, 공개 프록시(Proxy)는 수정 또는 보완이 필요

이 차이를 로그에 남기지 않으면, 원인을 잘못 파악하여 "Suno의 생성 실패"로 분류하게 됩니다. 올바른 판단은 "생성은 성공했으나, 공개 content 프록시가 상류 audio_url을 해결(Resolve)하지 못하고 있다"입니다.

다운로드 처리 시에는 최소한 다음 사항을 확인해야 합니다.

HTTP status: 200 또는 허용 가능한 206
Content-Type: audio/* 등과 같은 미디어 타입
Content-Length 또는 실제 다운로드 크기: 에러 페이지보다 충분히 커야 함
...

에러 페이지를 .mp3나 .mp4로 저장해 버리는 구현은 피해야 합니다.

1회차: succeeded 직후 다운로드
2회차: 10초 후
3회차: 30초 후
...

그럼에도 실패하는 경우에는 task_failed가 아니라 content_unavailable과 같이 분류하면 운영상의 구분이 쉬워집니다.

이번 포인트는 단순합니다.

공개 /content의 실패 = Suno 생성 실패

가 아닙니다.

Suno의 실제 미디어는 resultJson.data[0].audio_url에 있으며, 그곳으로부터는 정상적으로 MP3를 취득할 수 있었습니다. 프로덕션(Production) 환경에서는 이 URL을 명시적으로 해석하고, 필요에 따라 자사 스토리지에 저장하는 것이 안전합니다.