全部產品
Search
文件中心

Platform For AI:附錄:服務狀態代碼與常見報錯

更新時間:Nov 04, 2025

本文為您介紹訪問服務調用返回的狀態代碼和常見報錯。

狀態代碼說明

狀態代碼

說明

200

服務正常返回。

400

請求體(Body)格式錯誤或自訂Processor代碼異常。

說明

對於自訂Processor,如果代碼拋出異常,會在服務端返回狀態代碼400。建議在自訂Processor中指定返回其他狀態代碼,以區分代碼異常。

401

服務鑒權失敗。詳情見401 Authorization Failed

404

找不到服務。詳情見404 Not Found

405

方法不被允許。比如伺服器只支援GET請求,卻發送了POST請求就會返回405。嘗試更換要求方法。

408

請求計算逾時。服務端為每個請求配置了預設的逾時時間(預設為5秒,您可以在建立服務的JSON檔案中配置metadata.rpc.keepalive欄位來調整逾時時間),當單個請求的處理時間長度超過metadata.rpc.keepalive欄位配置的值後,服務端會返回狀態代碼408,來中斷該請求的處理,並斷開該請求所在的TCP串連。

說明

單個請求的處理時間長度包含Processor的計算時間、請求接收網路資料包時間以及單個請求在隊列中排隊的時間。

429

請求觸發限流。

  • 若使用共用網關,預設有限流策略:單服務為1000qps,伺服器組為 10000qps。由於共用網關由使用者共用頻寬,不適合對時延敏感和高並發的業務,建議使用專屬網關(無預設限流)。

  • EAS提供了基於QPS的限流功能,若請求並發數超出了指定限制後,超出的部分請求會被丟棄並返回狀態代碼429。該功能通過在JSON檔案中配置metadata.rpc.rate_limit欄位開啟。

450

超出隊列長度丟棄請求

499

用戶端主動中斷連線。當用戶端主動中斷連線時,用戶端不會接收到狀態代碼499,該串連上未處理完成的請求會在服務端記錄一個狀態代碼499。例如:在用戶端配置了HTTP逾時時間為30毫秒,服務端的處理延時為50毫秒,用戶端等待30毫秒後未擷取到返回結果時,會放棄該請求,並主動中斷連線,此時在服務端監控中,會出現狀態代碼499。

500

伺服器內部錯誤。伺服器遇到錯誤,無法完成請求。

501

尚未實施。伺服器不具備完成請求的功能。例如,伺服器無法識別要求方法時可能會返回此代碼。

502

錯誤網關。伺服器作為網關或代理,從上遊伺服器收到無效響應。

503

服務不可用。通過網關訪問服務時,如果後端服務執行個體狀態全部為非Ready,則網關會返回狀態代碼503。詳見503 no healthy upstream

504

網關逾時。詳見504 timeout

505

HTTP版本不受支援。伺服器不支援要求中所用的HTTP協議版本。

SDK調用錯誤碼

使用EAS提供的官方SDK進行服務調用時,部分錯誤碼為SDK轉換產生,並非服務端原始返回。請以網關和服務日誌中錯誤碼為準。

狀態代碼

說明

512

使用EAS Golang SDK調用服務,若用戶端主動中斷連線,將返回錯誤碼512。此類逾時斷開在服務端對應狀態代碼499。

常見報錯

404 Not Found

404 錯誤通常由無效的請求路徑、錯誤的請求體或服務不支援該介面導致。請根據收到的具體錯誤資訊,參考以下情境進行排查。

錯誤類型1:{"object":"error","message":"The model `` does not exist.","type":"NotFoundError","param":null,"code":404}

問題原因:調用vLLM部署的服務/v1/chat/completions 介面時,請求體中model參數值為空白或無效。

image

解決方案:model的參數值須為正確的模型名稱,可通過v1/models介面查詢。

錯誤類型2:{"detail":"Not Found"}

問題原因:請求路徑不完整或錯誤。例如,調用LLM服務對話介面,未在基礎地址後添加v1/chat/completions

image

解決方案:確保 API 請求路徑完整且正確。對於LLM服務,請參見LLM調用

錯誤類型3:調用 BladeLLM 的 /v1/models 介面,返回404: Not Found

問題原因:BladeLLM部署的服務不支援v1/models介面。

image

解決方案:請查閱BladeLLM服務調用參數配置說明擷取其支援的介面列表。

錯誤類型4:線上調試頁面返回 404,無其它資訊。

問題原因:請求路徑錯誤。如線上調試時,基礎地址通常是 http://123***.cn-hangzhou.pai-eas.aliyuncs.com/predict/服務名。錯誤地修改或刪除了 服務名會導致 404。

image

解決方案:線上調試時,通常不需要刪除或修改預設提供的地址,僅追加需要調用的具體API路徑。

錯誤類型5:API調用ComfyUI返回404 not found page

問題原因:通過 API 呼叫Serverless 版本的 ComfyUI 服務 ,該版本不支援 API調用。

解決方案:部署標準版或者API版,詳情請參見AI視頻產生-ComfyUI部署

400 Bad Request

請求體(Body)格式錯誤。請仔細檢查請求體格式(如JSON結構)、欄位名、資料類型是否正確。

401 Authorization Failed

訪問服務時Token未指定、不正確或使用方式錯誤。請檢查:

  • Token是否正確。服務概覽頁面,在基本資料地區單擊查看調用資訊

    說明

    鑒權Token預設後台自動產生,也可以通過自訂鑒權指定Token,並支援在服務更新時修改Token。

  • Token是否正確設定。

    • 使用curl命令,添加在HTTP要求標頭的Authorization欄位中。例如:curl -H 'Authorization: NWMyN2UzNjBiZmI2YT***' http:// xxx.cn-shanghai.aliyuncs.com/api/predict/echo

    • 在使用SDK訪問服務時,調用對應的SetToken()函數,詳情請參見Java SDK使用說明

504 timeout

伺服器作為網關或代理,但是沒有及時從上遊伺服器收到請求。這通常意味著模型推理耗時過長。解決方案:

  1. 在調用代碼中,主動延長HTTP請求的逾時時間。

  2. 對於耗時很長的任務,建議改用EAS的 佇列服務(非同步呼叫) 模式,它可以處理批量或長時間啟動並執行推理任務。

450 超出隊列長度丟棄請求

服務端的計算執行個體在接收到請求後,會先將請求放入隊列中進行排隊。當執行個體中的worker(worker數量預設為5,您可以在建立服務的JSON檔案中配置metadata.rpc.worker_threads欄位來調整worker數量)空閑時,會從隊列中擷取資料進行計算。當worker計算時間過長,導致隊列中請求堆積。當隊列打滿時(隊列長度預設為64,您可以在建立服務的JSON檔案中配置metadata.rpc.max_queue_size欄位來調整隊列長度),新來的請求會直接被拒絕,並返回狀態代碼450,來避免隊列過度堆積導致所有請求RT越來越高最終服務不可用。

說明

隊列限長在一定程度上也是一種限流保護,避免大流量導致服務雪崩。

處理方法

  • 當返回的狀態代碼有少量450時,因為服務端的執行個體是相互獨立的,您可以通過重試調度到其他相對閒置執行個體上,避免用戶端感知,但不能無限重試,否則限流的保護作用會失效。

  • 當Processor內部代碼卡住時,所有請求均返回狀態代碼450。當所有worker在處理請求時出現死結等情境,導致沒有worker從隊列中擷取資料進行處理,這種情境需要排查Processor代碼的Bug。

503 no healthy upstream

線上調試時報錯,錯誤碼為503,錯誤提示為“no healthy upstream”:

image

請如下排查:

  1. 查看執行個體狀態,如執行個體已停止,重啟服務即可。

  2. 如服務處於運行中狀態,可能是執行個體運行時資源不足,如CPU、記憶體和顯存被過度佔用,導致沒有足夠的緩衝餘量。

    • 當資源類型為公用資源時,建議稍後在非高峰時段再嘗試調用,或更換其他資源規格和地區。

    • 當資源類型為專屬資源(EAS資源群組)時,確保專屬資源群組為執行個體預留足夠的CPU、記憶體和顯存(建議至少保留20%空閑資源作為緩衝)。

  3. 還有一種比較常見的情境是,服務部署完成後狀態為Running,且服務各執行個體狀態均為Ready,但發起請求後觸發了代碼中的Bug,導致後端服務執行個體Crash,從而無法正常響應請求,此時網關會向用戶端返回狀態代碼503。請結合日誌修複Bug。

報錯:Unexpected token 12606 while expecting start token 200006

使用 vllm 部署 gpt-oss ,服務調用可能會出現以下錯誤:

image

解決方案:嘗試使用SGLang加速部署方式。

curl調用報錯no URL specified

使用如下命令發起請求後報錯no URL specified

curl -X http://17****.cn-hangzhou.pai-eas.aliyuncs.com/api/predict/service_name/**path** \
-H "Content-Type: application/json" \
-H "Authorization: **********==" \
-d '{"***":"****"}'

原因:curl命令使用了-X參數,但缺少了POST

調用返回ASCII 編碼

可參考如下樣本修改代碼:

from flask import Flask, Response

@app.route('/hello', methods=['POST'])
def get_advice(): 
    result = "result"
    return Response(result, mimetype='text/plain', charset='utf-8')

服務日誌中出現[WARN] connection is closed: End of file或Write a Invalid stream: End of file,如何解決?

用戶端與服務端之間的串連斷開,服務端在向該串連中回寫請求結果時,發現串連已斷開後所打的warning日誌,串連斷開一般分兩種情況:

  • 服務端逾時中斷連線:在Processor模式下,服務端預設逾時時間為5秒,您可以通過服務的metadata.rpc.keepalive參數來修改。在逾時時間到達後,服務端將關閉該串連,並在服務端的監控中記錄一個408狀態代碼。

  • 用戶端逾時中斷連線:用戶端的逾時時間由您的調用端代碼中設定的逾時時間決定。因逾時未返回HTTP響應,用戶端會主動中斷連線,此時服務端的監控記錄中會記錄一個499狀態代碼。

upstream connect error or disconnect/reset before headers. reset reason: connection termination

通常是由於長連線逾時導致請求失敗或執行個體負載不均衡等問題引起。服務端的處理超過用戶端配置的HTTP逾時時間後,用戶端會放棄該請求,主動中斷連線,此時服務端監控會出現狀態代碼499,可以查看監控指標進一步確認。對於推理耗時較長的情況,建議部署非同步推理服務

Tensorflow/Pytorch processor部署的服務要求線上調試失敗,如何解決?

出於效能考慮,TensorFlow/PyTorch Processor的Request Body採用非明文的protobuf格式。目前線上調試僅支援明文的文字格式設定輸入,因此該服務暫時無法在控制台上直接進行線上調試。您可以使用EAS配套提供的SDK來進行請求訪問,各語言版本SDK可參考:服務調用SDK