全部產品
Search

搜尋本產品

    CDN：緩衝相關常見問題

    文件中心

    CDN：緩衝相關常見問題

    更新時間：Jun 25, 2026

    本文為您介紹CDN緩衝相關的常見問題。

    瞭解基礎概念

    CDN緩衝清理機制是什嗎？

    緩衝在CDN節點上的資源，如果該資源的訪問熱度較低（同一個CDN節點上的同一個資源被用戶端訪問的頻次較低），那麼很可能會在緩衝到期之前被CDN節點上其他訪問熱度較高的資源覆蓋。

    CDN預設的緩衝規則是什嗎？

    CDN節點在收到來源站點響應的檔案資源的時候，會按照以下的緩衝規則來執行（數值越小，優先順序越高）：

    緩衝優先順序

    1. 來源站點響應pragma:no-cache、cache-control:no-cache（或者no-store，或者max-age=0）時，CDN遵循來源站點的策略，完全不緩衝資源。

    2. CDN控制台設定的緩衝到期時間或者狀態代碼到期時間。

      說明

      若CDN請求同時命中多條規則，有且僅有一條規則會生效，優先順序為：權重>規則建立時間。

      • 有多條緩衝規則的情況下，建議每條緩衝規則都設定不同的權重（權重越大優先順序越高），通過權重來控制規則執行優先順序。

      • 權重相同的規則生效優先順序：先建立的＞後建立的，與規則類型無關。

    3. 來源站點配置其他緩衝規則，優先順序由高至低為：cache-control>expires>last-modified>ETag。

      1. 如果來源站點響應中攜帶了cache-control，參數值包含max-age或s-maxage，並且max-age或s-maxage的值大於0，則使用cache-control設定緩衝到期時間，例如：cache-control:max-age=3600。如果同時存在max-age和s-maxage，則以s-maxage的值為準。

      2. 如果來源站點響應中沒有攜帶cache-control，但是攜帶了Expires，則使用Expires設定緩衝到期時間，例如：expires:Tue, 25 Nov 2031 17:25:43 GMT。

      3. 如果來源站點響應中沒有攜帶cache-control和Expires，但是攜帶了last-modified，則使用以下規則來計算緩衝時間：使用公式（目前時間-last-modified）* 0.1，計算結果在10秒~3600秒及之間的，取計算結果時間；小於10秒的，按照10秒處理；大於3600秒的，按照3600秒處理。

      4. 如果來源站點響應中沒有攜帶cache-control、Expires和last-modified，但是攜帶了ETag，緩衝10秒。

    4. 如果來源站點返回的資料中，cache-control、expires、last-modified和ETag這些緩衝策略相關的回應標頭都沒有攜帶，則預設不緩衝。

    緩衝策略中「來源站點響應 Cache-Control」的「來源站點」指什嗎？是指 OSS 配置還是 HTML 程式碼中的 <meta> 標籤？

    「來源站點」指 OSS、ECS 等後端儲存或應用伺服器返回的 HTTP 回應標頭，而非 HTML 程式碼中的<meta>標籤。

    CDN在判斷緩衝策略時，唯讀取來源站點在 HTTP 回應標頭中返回的Cache-Control、Expires等欄位；HTML <meta>標籤中的http-equiv="Cache-Control"僅對瀏覽器生效，CDN不會解析。

    緩衝配置新增的 4 個開關（優先遵循來源站點緩衝策略、忽略來源站點不緩衝標題、用戶端跟隨CDN緩衝策略、強制內容重新驗證）保持預設關閉，是否與舊版僅配置到期時間的效果一致？

    一致。以上 4 個開關預設均為「關閉」狀態時，CDN仍按控制台配置的緩衝到期時間規則進行緩衝，與未新增這些選項前的行為完全相同。各開關的具體作用請參見配置 CDN 緩衝到期時間中的操作步驟參數說明。

    建立CDN加速網域名稱時選擇不同業務類型（如圖片小檔案、大檔案下載等）是否會帶來預設的緩衝策略？

    建立CDN加速網域名稱時選擇的業務類型（如圖片小檔案、大檔案下載等）對預設緩衝策略影響不大，CDN並未針對特定尾碼或路徑預設固定的緩衝天數。

    實際的緩衝行為以控制台配置為準。建議在網域名稱建立後，前往配置 CDN 緩衝到期時間根據資源類型與更新頻率自行配置緩衝規則。

    節點HTTP回應標頭和回源HTTP回應標頭有什麼區別？或者說出站回應標頭和入站回應標頭有什麼區別？

    節點HTTP回應標頭和回源HTTP回應標頭在緩衝架構中代表不同環節的HTTP頭部資訊。

    • 節點HTTP回應標頭（出站回應標頭）：由CDN節點發送給用戶端（如瀏覽器）的HTTP回應標頭。當CDN節點有緩衝內容時，會直接返回給用戶端，無需向來源站點請求。

    • 回源HTTP回應標頭（入站回應標頭）：由來源站點發送給CDN節點的HTTP回應標頭。當CDN節點的緩衝到期或未命中時，CDN點會向來源站點請求最新內容，來源站點返回的內容及相關HTTP頭部資訊就是回源回應標頭。

    因此，節點HTTP回應標頭和回源HTTP回應標頭的區別在於它們的應用情境和控制對象不同。節點HTTP回應標頭用於控制用戶端和CDN節點的緩衝行為，而回源HTTP回應標頭用於控制來源站點與CDN節點之間的緩衝行為。它們通常共同使用，以實現高效、精確的緩衝控制。關於回源HTTP回應標頭的更多資訊，請參見修改入站回應標頭。

    異常狀態代碼（404、502等）的緩衝規則是什嗎？

    • 對於204、305、404、405、414、424、429、500、501、502、503和504狀態代碼，緩衝規則如下：

      1. 如果來源站點返回set-cookie回應標頭，CDN不緩衝。

      2. 如果來源站點沒有返回Set-Cookie回應標頭，則遵循CDN控制台配置的狀態代碼到期時間來緩衝，配置多條規則時生效方式請參考多條規則生效優先順序說明。

      3. 如果來源站點沒有返回Set-Cookie回應標頭，CDN控制台也沒有配置狀態代碼到期時間，則按照來源站點設定的Pragma、Cache-Control或者Expires回應標頭來緩衝。

      4. 如果來源站點沒有返回Set-Cookie、Pragma、Cache-Control或者Expires回應標頭，CDN控制台也沒有配置狀態代碼到期時間，則預設緩衝1秒。

    • 對於302、307和403狀態代碼，緩衝規則如下：

      1. 如果來源站點返回set-cookie回應標頭，CDN不緩衝。

      2. 如果來源站點沒有返回Set-Cookie回應標頭，則遵循CDN控制台配置的狀態代碼到期時間來緩衝，配置多條規則時生效方式請參考多條規則生效優先順序說明。

      3. 如果來源站點沒有返回Set-Cookie回應標頭，CDN控制台也沒有配置狀態代碼到期時間，則按照來源站點設定的Pragma、Cache-Control或者Expires回應標頭來緩衝。

      4. 如果來源站點沒有返回Set-Cookie、Pragma、Cache-Control或者Expires回應標頭，CDN控制台也沒有配置狀態代碼到期時間，不緩衝。

    • 針對304狀態代碼，CDN將不進行緩衝，且無法通過任何方式設定緩衝時間。

    CDN是否支援多副本緩衝？如何?CDN的多副本緩衝？

    CDN支援預設多副本緩衝。此時來源站點需要攜帶Vary頭來告知CDN節點需要用哪個要求標頭的值來做多副本。

    以壓縮為例，當用戶端發送 Accept-Encoding: gzip 時，來源站點會返回經過 gzip 壓縮的內容；而如果用戶端發送的是 Accept-Encoding: br，來源站點則返回使用 Brotli 壓縮的內容。為了緩衝這些不同版本的響應，就需要來源站點在響應中添加 Vary 頭，明確告知緩衝系統根據哪個要求標頭來區分不同的副本。在本例中，來源站點應設定 Vary: Accept-Encoding，表明需要根據 Accept-Encoding 的值來儲存和提供不同的快取複本。

    緩衝配置

    如何設定緩衝全域生效？

    您可以通過設定緩衝到期時間來實現緩衝全域生效。設定時，类型選擇目录後，在地址欄用正斜線（/）匹配所有目錄。具體操作請參見配置CDN緩衝到期時間。

    如何配置整個網域名稱不緩衝？

    為了配置阿里雲CDN整個網域名稱不緩衝，您可以通過設定全路徑緩衝到期時間為0來實現，並確保該規則權重最高。以下是具體步驟：

    1. 登入CDN控制台。

    2. 在左側導覽列，單擊域名管理。

    3. 在域名管理頁面，找到目標網域名稱，單擊操作列的管理。

    4. 在指定網域名稱的左側導覽列，單擊缓存配置。

    5. 在缓存过期时间頁簽下，單擊添加。

      • 类型：選擇目录。

      • 地址：填寫/，表示全部路徑。

      • 过期时间：填寫0秒。

      • 其他參數保持預設選項。

    6. 單擊確定，完成配置。

    說明

    若阿里雲CDN請求同時命中多條規則，有且僅有一條規則會生效，優先順序為：權重>規則建立時間。

    如果缓存过期时间中有多條規則，請保證全網域名稱不緩衝規則的权重最高（此時優先順序最高）。

    如何配置CDN僅緩衝靜態檔案（如圖片、CSS、JS），而讓動態網頁面直接回源？

    建議採用"黑白名單"結合權重的配置方式：

    1. 建立高權重靜態緩衝規則：添加一條或多條規則，類型選擇"檔案尾碼名"，地址填寫 jpg,png,css,js 等靜態尾碼，設定較長的緩衝時間（如1個月），權重設為較高值（如90～99）。

    2. 建立低權重動態不緩衝規則：添加一條規則，類型選擇"目錄"，地址填寫 /（根目錄），緩衝時間設為 0 秒（不緩衝），權重設為較低值（如1～10）。

    3. 針對特定動態路徑最佳化：若某些動態路徑（如 /api/ 或 /wp-admin/）需要嚴格不緩衝，可單獨添加目錄規則，路徑設為該目錄，緩衝時間 0 秒，權重設為最高（如99），確保優先匹配。

    注意：CDN無法完全繞過節點直接回源，即使緩衝時間為 0，請求仍會經過CDN節點進行轉寄和鑒權。

    動態資源、介面或特定目錄如何配置不緩衝（透傳回源）？

    針對不同的動態內容情境，可以通過配置緩衝到期時間為 0 秒來實現透傳回源：

    • 動態網頁面和介面不緩衝：對於 PHP、ASPX、API 介面、即時通訊（長串連）、後台上傳介面等動態內容，添加一條文件后缀名規則，輸入對應尾碼（如php,aspx,jsp），將过期时间設定為 0 秒。這樣可確保每次請求即時回源，避免因緩衝動態內容導致驗證碼失效、登入狀態異常或圖片上傳失敗等業務問題。

    • 指定目錄不緩衝：若需對特定目錄（如/api/、/wp-admin/）實作類別似"關閉加速"的效果，添加一條目录規則，填寫目標目錄路徑，將到期時間設定為 0 秒。CDN 不支援直接關閉某個目錄的加速，但通過此方式可實現請求透傳回源。

    • 根目錄與子目錄優先順序配置：若希望僅緩衝特定子目錄（如/static/）而根目錄/下的其他資源不緩衝，需分別配置兩條規則。將子目錄/static/的权重設為較高值（如 99），將根目錄/的緩衝到期時間設為 0 秒且權重設為較低值（如 1）。如果全站緩衝導致動態介面異常，建議刪除全站緩衝規則，改為按檔案尾碼名或具體靜態目錄分別配置。

    • SPA/HTML 頁面緩衝異常：若 SPA（單頁應用）頁面出現 404 或登入跳轉異常，檢查是否對.html或index.html配置了緩衝。建議對 HTML 檔案設定不緩衝（到期時間為 0 秒），或在來源站點回應標頭中去除Cache-Control，然後執行重新整理緩衝操作。

    說明

    即使緩衝到期時間設為 0 秒，請求仍會經過 CDN 節點進行轉寄和安全校正，無法完全繞過 CDN。更多關於檔案不緩衝的情境說明，請參見緩衝相關常見問題。

    將緩衝規則中的檔案尾碼設為 .aspx 是否會導致整站不緩衝？

    如果您的網站全部頁面都是.aspx結尾，將.aspx尾碼的緩衝到期時間設為 0，會導致整站不緩衝。

    建議避免使用泛尾碼對整站生效。請針對具體檔案路徑或目錄配置緩衝規則，例如對/static/目錄設定較長緩衝時間，對/api.aspx這類動態介面單獨設定 0 秒不緩衝。

    如何為 robots.txt 和 sitemap.xml 配置緩衝時間長度？

    這兩類檔案直接影響搜尋引擎抓取，需要根據更新頻率單獨配置緩衝時間長度，避免命中預設規則後過長緩衝導致更新延遲：

    類型

    推薦配置

    說明

    檔案尾碼名

    txt,xml

    在控制台「緩衝到期時間」添加規則，類型選「檔案尾碼名」，到期時間根據更新頻率設定（建議 1 小時～1 天）

    目錄或檔案路徑

    /robots.txt、/sitemap.xml

    若只針對這兩個檔案，類型選「目錄」，地址填具體檔案路徑，權重設高以覆蓋泛尾碼規則

    若網站會頻繁更新 sitemap，建議緩衝時間長度不超過 1 小時；若 robots 規則穩定，可設定較長緩衝。

    「用戶端跟隨緩衝策略」開關應該開啟還是關閉？

    該開關控制CDN是否將自身的緩衝策略（如max-age=3600）通過回應標頭傳遞給用戶端瀏覽器：

    • 關閉（預設）：CDN節點仍按自身規則緩衝資源，但不會在回應標頭中告知瀏覽器。此時瀏覽器的緩衝行為完全由您在「修改出站回應標頭」中手動設定的欄位決定。

    • 開啟：CDN將Cache-Control等頭部一併下發給瀏覽器，使瀏覽器與CDN節點採用相同的緩衝策略。

    建議若已在「修改出站回應標頭」中針對用戶端配置了所需回應標頭，且與預期一致，保持預設關閉即可。若希望瀏覽器複用CDN的策略以減少二次載入請求，可開啟。

    CDN如何緩衝大檔案？

    CDN支援大檔案下載情境的緩衝，可通過配置緩衝到期時間規則讓CDN節點長期緩衝該類檔案，提升命中率並降低回源成本。

    配置建議：

    • 緩衝時間長度：不常更新的大檔案建議設定 ≥1 個月的緩衝到期時間。

    • 來源站點不緩衝指令：確保來源站點未返回Cache-Control: no-cache、no-store、max-age=0等指令。若來源站點不可控，可在緩衝規則中勾選「忽略來源站點不緩衝標題」。

    • 大檔案預熱：首次訪問大檔案時延遲較高，建議在分發前通過重新整理和預熱資源提交預熱任務，將檔案提前推送至CDN節點。

    CDN如何配置子目錄訪問首頁？

    通過訪問子目錄名來返回預設的子目錄首頁是網站常見的操作之一，在CDN上也可以實現這個能力，減少來源站點改動。

    例如，首頁檔案是https://www.example.com/cdn/index.html，該方案可以實現訪問https://www.example.com/cdn、https://www.example.com/cdn/子目錄也可以返回首頁檔案。

    確認來源站點

    先確認來源站點的子目錄首頁具體檔案可以訪問，例如https://www.example.com/cdn/index.html可以正常訪問到。

    配置子目錄重寫

    1. 登入CDN控制台。

    2. 在左側導覽列，單擊域名管理。

    3. 在域名管理頁面，找到目標網域名稱，單擊操作列的管理。

    4. 在指定網域名稱的左側導覽列，單擊缓存配置。

    5. 單擊重寫訪問URL頁簽。

    6. 單擊添加，根據您的實際需求，配置訪問URL重寫參數。

      配置兩條規則，分別針對結尾是/和結尾不是/的進行匹配：

      • 規則1：待重寫的Path：^/(.+)/$；目標Path：/$1/index.html；執行規則：Break。

      • 規則2：待重寫的Path：^/([^.?#]+)$；目標Path：/$1/index.html；執行規則：Break。

      image

    通過HTTP回應標頭配置CDN跨域資源共用（CORS）及注意事項

    設定適當的HTTP回應標頭，允許來自不同源的請求訪問資源，詳情請參見配置跨域資源共用。

    驗證緩衝效果

    如何判斷CDN緩衝是否成功？

    阿里雲CDN對於檔案是否支援緩衝，您可以通過檢查HTTP回應標頭中的相關欄位來判斷。

    1. X-Cache: 表示請求是否命中CDN緩衝。值為HIT表示命中，MISS或者欄位不存在表示未命中。

    2. Age: 表示檔案在CDN節點上緩衝的時間（秒）。檔案被重新整理或首次訪問無此欄位。Age為0表示緩衝到期，需回源校正。

    3. X-Swift-CacheTime: 表示檔案在CDN節點上的允許緩衝時間。計算剩餘緩衝時間：X-Swift-CacheTime – Age。

    4. X-Swift-SaveTime：表示資源首次被緩衝到CDN節點上的時間（GMT）。轉換為中國北京時間需加上8小時。

    為了查看這些HTTP回應標頭，您可以通過以下兩種方式查看您的內容是否緩衝到CDN：

    方式1：使用瀏覽器的開發人員工具（如Chrome的開發人員工具）

    在瀏覽器開發人員工具的 Network 面板中查看 Response Headers，重點關注與 CDN 緩衝相關的回應標頭欄位 Age、X-Cache、X-Swift-Cachetime 和 X-Swift-Savetime。

    Response Headers
Access-Control-Allow-Origin:    *
Age:    860
Ali-Swift-Global-Savetime:    1704259214
Cache-Control:    max-age=28800,s-maxage=3600
Content-Encoding:    gzip
Content-Length:    2618
Content-Md5:    /h0oxujZUUo1P8gMA893oQ==
Content-Type:    text/html
Date:    Wed, 03 Jan 2024 05:20:14 GMT
Eagleid:    db9062a517042600741495981e
Server:    Tengine
Timing-Allow-Origin:    *
Vary:    Accept-Encoding
Via:    cache49.l2cn3032[0,0,200-0,H], cache8.l2cn3032[3,0], cache8.l2cn3032[3,0], ens-cache16.cn3573[0,0,200-0,H], ens-cache17.cn3573[43,0]
X-Cache:    HIT TCP_MEM_HIT dirn:10:498457979
X-Oss-Hash-Crc64ecma:    1068125902847643907
X-Oss-Object-Type:    Normal
X-Oss-Request-Id:    6594EE8E1FC2C239355F41E1
X-Oss-Server-Time:    3
X-Oss-Storage-Class:    Standard
X-Source-Scheme:    https
X-Swift-Cachetime:    3600
X-Swift-Savetime:    Wed, 03 Jan 2024 05:20:14 GMT
X-Swift-Savetime:    Wed, 03 Jan 2024 05:20:14 GMT

    方式2：使用curl命令查看資源緩衝情況

    curl "http://example.com/path/to/response.html" -v
    F:\test>curl http://cdn.xxx.top/pic_03.jpg -v
* Host cdn.xxx.top:80 was resolved.
* IPv6: (none)
* IPv4: 1xxx
*   Trying 1xxx:80...
* Connected to cdn.xxx.top (xxx) part 80
> GET /pic_03.jpg HTTP/1.1
> Host: cdn.xxx.top
> User-Agent: curl/8.9.1
> Accept: */*
>
* Request completely sent off
&lt; HTTP/1.1 200 OK
&lt; Server: Tengine
&lt; Content-Type: image/jpeg
&lt; Content-Length: 8775526
&lt; Connection: keep-alive
&lt; Date: Mon, 26 May 2025 02:21:59 GMT
&lt; x-oss-request-id: 68xxx9A
&lt; x-oss-cdn-auth: success
&lt; Accept-Ranges: bytes
&lt; ETag: &quot;Bxxx2&quot;
&lt; Last-Modified: Tue, 03 Sep 2024 06:20:19 GMT
&lt; x-oss-object-type: Normal
&lt; x-oss-storage-class: Standard
&lt; Via: cache20.l2cn3032[0,0,200-0,H], cache10.cn3573[0,0,200-0,H], cache10.cn3573[1,0]
&lt; Age: 424
&lt; X-Cache: HIT TCP_HIT dirn:0:698837654
&lt; X-Swift-CacheTime: 2592000
&lt; Timing-Allow-Origin: *
&lt; EagleId: 08xxx51
&lt;
* Connection #0 to host cdn.xxx.top left intact

    &lt; x-oss-hash-crc64ecma: 12xxx58 &lt; x-oss-storage-class: Standard &lt; x-oss-server-time: 228 &lt; Via: ens-cache3.12cn7857[1863,1862,206-0,M], ens-cache38.12cn7857[1863,0], ens-cache20.cn6692[0,0,200-0,H], ens-cache4.cn6692[14,0] &lt; Age: 424 &lt; Ali-Swift-Global-Savetime: 1748226119 &lt; X-Cache: HIT TCP_HIT dirn:7:286737139 mlen:0 &lt; X-Swift-SaveTime: Mon, 26 May 2025 02:21:59 GMT &lt; X-Swift-CacheTime: 2592000 &lt; Timing-Allow-Origin: * &lt; EagleId: 7xxx220e

    回應標頭中 <code data-tag="code">X-Cache: HIT TCP_HIT 表明該資源已被 CDN 快取命中，Age: 424 表示資源在緩衝中已儲存 424 秒，X-Swift-CacheTime: 2592000 表示緩衝有效期間為 2592000 秒（30 天）。

    配置緩衝規則後，為什麼測試請求仍然回源或未命中緩衝？

    可按以下步驟排查：

    1. 檢查配置生效狀態：確認控制台緩衝配置狀態顯示為"成功"。

    2. 驗證匹配優先順序：若存在多條規則，確保目標路徑命中的規則權重最高。例如，具體目錄（如 /static/）的權重應高於根目錄（/）的預設規則。

    3. 檢查來源站點回應標頭：若來源站點返回 Cache-Control: no-cache/no-store/max-age=0 或 Pragma: no-cache，且CDN未開啟"忽略來源站點不緩衝標題"，CDN將遵循來源站點指令不緩衝。建議開啟該選項或調整來源站點配置。

    4. 確認要求方法：使用 curl -voa（GET請求）而非 curl -I（HEAD請求）進行測試，因為HEAD請求可能不會觸發L1節點對資源體的真實緩衝邏輯，導致誤判為MISS。

    5. 檢查URL參數：若URL帶參數，確認是否開啟了"忽略URL參數"功能。若未開啟，不同參數的URL被視為不同資源；若開啟，則視為同一資源。

    修改緩衝規則後，狀態顯示"配置中"，是否正常？是否影響業務？

    • 配置狀態說明：新增或修改緩衝規則後，規則状态顯示"配置中"是正常現象，表示配置正在下發到全網 CDN 節點。通常幾分鐘內會自動變為"成功"。如果長時間未變化，可嘗試重新整理頁面查看最新狀態。

    • 業務影響：修改緩衝規則不會影響現有業務的可用性。新規則僅對新請求生效，已經緩衝在 CDN 節點上的資源仍按照舊策略提供服務，直至緩衝到期。如果需要新規則立即對所有請求生效，請執行重新整理緩衝操作清除舊緩衝。

    緩衝重新整理

    來源站點變更檔案後，CDN節點上的緩衝會主動、即時更新嗎？

    來源站點變更檔案後，CDN節點上的緩衝不會主動、即時更新。緩衝更新取決於配置的緩衝策略。

    • CDN節點根據配置的緩衝到期時間更新緩衝。如果緩衝未到期，來源站點變更檔案不會立即反映在CDN緩衝中，詳情請參見配置CDN緩衝到期時間。

    • 您可以通過CDN提供的重新整理緩衝手動清除緩衝，使下一次請求回源擷取最新的內容。

    配置 Cache-Control: no-cache 後能否保證使用者不清理瀏覽器緩衝即可重新整理訪問最新檔案？

    不能保證。Cache-Control: no-cache僅讓用戶端在每次請求時向CDN發起協商緩衝請求，若CDN節點上仍緩衝有舊檔案且未到期，CDN可能直接返回緩衝內容或需回源驗證。若來源站點檔案已更新但CDN未重新整理，使用者仍可能看到舊檔案。

    建議在來源站點更新檔案後，通過CDN控制台執行重新整理或預熱操作（詳情請參見重新整理和預熱資源），強制CDN節點回源擷取最新資源，從而確保使用者訪問到最新檔案。

    如何?分鐘級或近即時更新CDN緩衝？

    通過以下步驟實現分鐘級更新：

    1. 在CDN控制台為目標檔案配置緩衝到期時間（如 60 秒）。

    2. 開啟「強制內容重新驗證」開關。

    3. 關閉「優先遵循來源站點緩衝策略」開關。

    如果之前配置了較長的緩衝時間，需要先通過重新整理和預熱資源清除舊緩衝，新配置才能立即生效。

    若需毫秒級即時性，建議在來源站點使用版本化檔案名稱（如style-a1b2c3d.css）替代緩衝策略調整，詳情請參見配置 CDN 緩衝到期時間。

    緩衝不更新時是否需要修改到期時間？

    不需要修改到期時間。只需以下兩步即可讓單次更新立即生效：

    1. 開啟「強制內容重新驗證」開關，關閉「優先遵循來源站點緩衝策略」開關。

    2. 在重新整理和預熱資源中提交對應檔案的重新整理任務。

    此操作僅清除已緩衝的舊內容，下一次請求會回源擷取最新資源，不影響後續訪問的快取命中率。

    排查異常問題

    在控制台緩衝到期時間設定為0，為何訪問到的資源仍然不是最新內容？

    在CDN控制台將緩衝到期時間設定為0，目的是每次請求都直接回來源站點擷取最新內容。然而，如果您發現訪問到的資源仍然不是最新的內容，可能有幾個原因：

    1. 瀏覽器本機快取：瀏覽器可能緩衝了舊內容。建議清除瀏覽器緩衝或使用無痕模式測試。

    2. 配置生效延遲：設定緩衝時間為0後，可能需要時間讓所有CDN節點生效。另外，如果CDN節點未檢測到更改，可能仍返回舊緩衝。

    3. 來源站點緩衝未重新整理：來源站點伺服器可能有緩衝機制，未及時更新時，CDN節點回源可能擷取舊緩衝。

    4. 節點緩衝清除延遲：修改配置前已緩衝的資源可能需要時間清除。您可以手動重新整理緩衝，確保立即擷取最新內容，詳情請參見重新整理和預熱資源。

    緩衝配置為什麼沒有生效？

    如果您配置了緩衝規則，在使用過程中發現此緩衝規則未生效，可能是以下原因：

    1. 生效延遲：緩衝規則的修改或新增通常需要一段時間才會生效，請您在規則生效後再驗證。

    2. 緩衝更新機制：新規則不會立即應用到已緩衝的內容，需要等到原緩衝到期後才會生效。

    3. 緩衝重新整理操作未執行：更改緩衝設定後，如果沒有手動重新整理緩衝，舊的緩衝內容將繼續被提供給使用者，直到自然到期。詳情請參見重新整理和預熱資源。

    4. 緩衝回應標頭設定不當：檢查來源站點發送的HTTP回應標頭裡的Cache-Control和Expires標題是否正確設定。

    5. 緩衝規則有優先順序：若CDN請求同時命中多條規則，優先順序為：權重>規則建立時間。

      • 有多條緩衝規則的情況下，建議每條緩衝規則都設定不同的權重（權重越大優先順序越高），通過權重來控制規則執行優先順序。

      • 權重相同的規則生效優先順序：先建立的＞後建立的，與規則類型無關。

      配置樣本：為加速網域名稱demo.aliyun.com配置以下緩衝策略，CDN節點回源下載資源http://demo.aliyun.com/image/example.png，雖然以下兩條規則都匹配到了，但是因為這兩條規則的權重相同，因此要判斷規則建立的時間，先建立的規則優先順序高於後建立的，因為目錄/image這條規則建立的時間更早，所以系統最終生效的是目錄類型這條規則。緩衝規則配置列表展示兩條規則： - 地址為jpg,png，類型為檔案尾碼名，到期時間1個月，權重10，狀態為成功。 - 地址為/image，類型為目錄，到期時間1天，權重10，狀態為配置中。 兩條規則的遵循來源站點緩衝策略、忽略來源站點不緩衝標題、用戶端跟隨CDN緩衝策略、強制內容重新驗證均為關閉。每條規則支援修改和刪除操作。

    為什麼已經配置了回應標頭Access-Control-Allow-Origin，但是訪問資源仍提示跨域問題，response header中沒有配置的回應標頭？

    如果您在阿里雲CDN中配置了Access-Control-Allow-Origin等回源回應標頭，但用戶端仍遇到跨域問題且回應標頭中沒有這些配置，可能原因如下：

    可能的原因

    1. 配置未生效或錯誤：配置未正確設定或尚未生效。

    2. CDN緩衝：CDN節點緩衝了舊的回應標頭。

    3. 來源站點問題：來源站點的跨域回應標頭與CDN配置衝突。

    4. 瀏覽器緩衝：瀏覽器緩衝了舊的響應。

    解決方案

    1. 驗證配置：確認CDN配置已正確設定並生效。

    2. 清除CDN緩衝：使用CDN的重新整理功能清空緩衝，然後再次訪問資源。具體請參見重新整理和預熱資源。

    3. 檢查來源站點設定：確認來源站點不會返回與CDN配置衝突的跨域回應標頭。建議統一來源站點和CDN的跨域頭設定。

    4. 清除瀏覽器緩衝：清空瀏覽器緩衝，或使用無痕模式測試。

    視頻播放出現 ERR_CONTENT_LENGTH_MISMATCH 錯誤，如何排查？

    • 錯誤原因：該錯誤通常是因為 CDN 節點上緩衝的檔案長度與來源站點實際內容不一致，或來源站點返回了異常的Content-Length回應標頭。常見於來源站點更新了視頻檔案內容但 CDN 仍返回舊版本緩衝。

    • 解決方案：

      1. 在 CDN 控制台的重新整理預熱頁面，提交視頻 URL 的重新整理請求，清除 CDN 節點上的舊緩衝。

      2. 如果來源站點為 OSS（Object Storage Service），可開啟 CDN 緩衝自動重新整理功能，使來源站點檔案更新後自動觸發 CDN 緩衝重新整理。

      3. 檢查來源站點的穩定性和響應一致性，確保來源站點不會間歇性返回異常Content-Length。

    • 206 狀態代碼說明：視頻播放器通常使用 Range 請求分段載入視頻內容，CDN 返回206 Partial Content狀態代碼屬於正常行為。即使命中 CDN 緩衝，返回的也是 206 狀態代碼，不屬於錯誤。、

    靜態檔案已命中CDN緩衝，但首頁仍然載入很慢？

    靜態資源（圖片、CSS、JS 等）已命中緩衝並正常加速，但首頁（根路徑 /）載入仍需數秒，通常是因為首頁請求未配置緩衝規則，每次訪問都需要回源擷取資料，載入速度取決於來源站點處理耗時。

    解決方案：為加速網域名稱添加根目錄的緩衝到期時間規則，使首頁內容被CDN節點緩衝，減少回源次數。

    1. 登入CDN控制台。

    2. 在左側導覽列，單擊域名管理。

    3. 在域名管理頁面，找到目標網域名稱，單擊操作列的管理。

    4. 在指定網域名稱的左側導覽列，單擊缓存配置。

    5. 在缓存过期时间頁簽下，單擊添加。

      • 类型：選擇目录。

      • 地址：填寫/。

      • 过期时间：根據首頁內容的更新頻率設定，例如 30 秒至數分鐘。

      • 权重：若已有其他緩衝規則，將此規則的權重設為較低值（如 1），避免覆蓋靜態資源的緩衝規則。

    6. 單擊確定，完成配置。

    配置生效後，首頁內容將被CDN節點緩衝，後續訪問直接從節點返回，不再每次回源，首頁載入速度將顯著提升。更多關於緩衝到期時間的配置說明，請參見配置 CDN 緩衝到期時間。

    最佳化快取命中率

    如何解決URL的傳遞參數為變數導致CDN快取命中率低的問題？

    可能是因為沒有開啟CDN的忽略參數功能，詳情請參見URL的傳遞參數為變數導致CDN快取命中率低。

    影響CDN快取命中率下降的因素有哪些？

    影響阿里雲CDN快取命中率下降的因素如下：

    1. 重新整理緩衝：手動或自動重新整理快取作業可能導致短時間內命中率下降。

    2. 頻寬突增：當頻寬在短時間內大幅度增加時，會導致CDN節點回源請求增多，從而降低快取命中率。

    3. CDN節點訪問新內容：如果CDN節點頻繁訪問首次請求的新內容，也會導致回源較多，進而表現出快取命中率的下降趨勢。

    4. 緩衝規則調整：對CDN緩衝策略進行修改或調整可能會影響快取命中率，例如未配置合適的緩衝到期時間或者緩衝原則設定不當。

    5. URL中帶有可變參數：URL中問號（?）後的參數變化會導致不同的URL請求被視為不同的資源，即使實際指向的是同一份內容，這也會造成CDN快取命中率降低。

    6. 未合理配置緩衝到期時間：對於不同更新頻率的靜態檔案，如未根據實際情況設定合理的緩衝到期時間，可能會導致緩衝資源過早失效，從而影響快取命中率。

    更多情境關於影響快取命中率的因素介紹請參見提高CDN快取命中率。具體可參見重新整理和預熱資源、忽略參數和配置CDN緩衝到期時間。

    怎麼排查快取命中率低、回源率高或來源站點頻寬跑滿？

    • 檢查來源站點緩衝回應標頭：如果來源站點返回Cache-Control: no-cache、Cache-Control: no-store、Cache-Control: max-age=0或Pragma: no-cache，CDN 預設遵循來源站點指令不緩衝該資源，導致每次請求均回源。這是命中率低和來源站點頻寬跑滿最常見的原因。

    • 開啟忽略來源站點不緩存標題：在 CDN 控制台的緩衝到期時間配置中，勾選該選項。開啟後，CDN 將忽略來源站點返回的Cache-Control: no-cache、no-store、max-age=0以及Pragma: no-cache等不緩衝指令，強制按控制台配置的規則進行緩衝。

    • 檢查緩衝規則配置：確認是否誤將根目錄/的緩衝到期時間配置為 0 秒。如果根目錄規則權重最高且到期時間為 0，則所有請求都會回源。

    • 大檔案情境最佳化：對於視頻等大檔案，確保已開啟 Range 回源功能，避免每次請求都回源擷取完整檔案。

    • 區分動靜資源：為靜態資源（圖片、CSS、JS 等）設定較長的緩衝時間（如 1 個月），為動態內容（如 PHP、JSP）設定到期時間為 0 秒（不緩衝）。

    說明

    更詳細的快取命中率排查方法，請參見CDN 快取命中率較低排查方法。

    為什麼視頻播放或大檔案下載時，日誌中顯示大量 206 狀態代碼或多次回源？

    這是正常現象。

    1. 206狀態代碼：視頻播放器或下載工具通常使用Range請求分段載入資源，每次請求部分內容，伺服器返回 206 Partial Content。CDN命中緩衝時也會返回 206。

    2. 流量費用：只要用戶端向CDN發起請求並接收資料，無論是否命中緩衝，均會計入CDN流出流量費用。

    3. 最佳化建議：確保開啟CDN的Range回源功能，以便CDN節點可以按需從來源站點拉取片段並緩衝，提高後續分段請求的命中率。同時，建議在用戶端或來源站點配置合理的 Cache-Control 頭，利用瀏覽器本機快取減少重複請求。

    其他緩衝相關常見問題，請參見緩衝相關常見問題。