在這一連串恢復正常縮圖的過程中，最讓我意外的除錯環節就是－LiteSpeed 的過度保護陷阱。這個問題發現是在問題進行到很後頭的時候，我在把網址貼上臉書偵錯系統進行偵錯時，出現了「無法以圖像的方式處理提供的 og:image 網址」的訊息，這才間接抓出原來社群貼文縮圖有問題，很有可能也跟主機所使用的伺服器有關聯。
也就是說當我們網站上傳的圖片明明打得開，文章也有設有精選圖片，但只要把網址貼到社群上，畫面只有網址不見縮圖，去搜尋解決辦法，通常是會建議去臉書偵錯系統重新抓取資料，此時若出現「無法以圖像方式處理提供的 og:image 網址，因為內容類型無效」之之類的訊息，那極有可能就是遇到跟我雷同的問題了。
這個問題看起來像是圖片壞了、設定錯了，實際上卻很有可能是跟我們所使用的伺服器架構有關，也就說若和我一樣，使用的是 Hostinger，或是中文教學資料頗多的 NameHero、A2 Hosting 這類預設搭載 LiteSpeed 伺服器 的 WordPress 主機，那就很可能遇到所謂的：
LiteSpeed 的過度保護陷阱
LiteSpeed 是什麼？為什麼越來越多 WordPress 主機用它？
首先，不要因為這個圖片縮圖問題只在 LiteSpeed 環境中出現，就覺得它是「爛伺服器」，事實正好相反：LiteSpeed 是一款兼具效能與速度的高性能 Web Server，代表你不需要自己調整什麼底層設定，就能享有伺服器級別的加速效能與自動快取機制，這些讓使用者的使用體感極佳的關鍵，也是它越來越受到國內外主機商的青睞採用的主要原因。
根據 W3Techs 截至 2025 年 5 月的統計，LiteSpeed 在全球網站伺服器市場的市佔率約為 14.1%，在中文教學資源較多、台灣使用者也比較熟悉的主機商中，國外的 A2 Hostin、NameHero，國內的遠振資訊、網易虛擬主機，都是預設使用 LiteSpeed 作為伺服器環境。
LiteSpeed 的主要優勢分別為：
- 高效能與低資源消耗：相較於傳統的 Apache 伺服器，LiteSpeed 採用事件驅動架構，能以更少的資源處理更多的請求。
- 與 Apache 相容：支援 Apache 的配置檔案 （ 如 .htaccess），方便從 Apache 遷移，能沿用
.htaccess、mod_rewrite 等機制，不用重新學習。 - 內建LSCache 快取功能：與 WordPress 專用外掛 LiteSpeed Cache（LSCWP） 整合，可做到比 WP Super Cache、W3TC 等快取外掛更快速、更省資源的頁面快取。
- 自動防盜連保護：透過檢查 HTTP 請求中的 Referer 標頭，防止其他網站直接連結您的圖片或資源，避免不必要的頻寬消耗。
- 支援最新協定：LiteSpeed 支援 HTTP/3 和 QUIC 協定，提供更快的連線速度和更佳的安全性。
然當中的「自動防盜連保護」，就是這篇要來討論的保護過度所衍伸出來的縮圖消失問題。
根本原因：LiteSpeed 圖片防盜連機制，讓它「誤傷友軍」
LiteSpeed 為了保護網站資源，尤其是圖片這類媒體檔案，通常會啟用「防盜連機制」。這種機制會檢查每一筆請求的來源 （ 也就是 HTTP_REFERER），只允許來自網站本身的訪問，如果發現圖片是被其他網站直接嵌入的，就會擋下請求，並拒絕載入。這種防止別人盜連我們的圖片，進而吃掉我們主機的流量的作法而言，是一種節省資源兼務實的做法。
因此，在伺服器或 .htaccess 裡，LiteSpeed 通常會預設加上一段像這樣的規則：「如果圖片請求不是從我們自己的網站來的，就擋掉它」，但問題也就出在這裡，像 Facebook、LINE、Twitter 等社群平台，在使用者貼上連結時，會先用自己的「機器人」來預抓網站內容，也就是會去讀你網站的 <meta> 裡的 og:image 來顯示縮圖。
然而問題就出在這裡，這些社群平台的機器人，也就是所謂的「爬蟲」，雖然是合法的抓取工具，但它們在抓取 og:image 縮圖時，是透過「程式」（ 而非瀏覽器 ） 直接去讀取圖片連結，而這些程式在發送請求時，很多情況下不會附帶 HTTP_REFERER，或者即便有附，也可能是不完整或非預期的格式。
這就導致伺服器 （ 如 LiteSpeed） 無法判斷這些圖片請求從哪裡來，誤以為這是來自陌生網站的圖片盜連行為，這就觸發了 LiteSpeed 自動啟動防盜連機制，不僅不給程式請求的圖片，且還直接拒絕請求，甚至回傳錯誤格式的 HTML 頁面。這也就導致社群平台讀不到正確的圖片，產生各種縮圖異常問題，這是我們肉眼可以見到的三種縮圖出包的情況：
- Facebook 提示圖片無法使用：
og:image 無效或格式錯誤 - LINE 貼文完全沒預覽卡片：只剩一串網址
- Google 搜尋不顯示縮圖小圖示：因為抓不到圖片，搜尋結果右邊是顆小地球
解決方法：修改 .htaccess 來告訴伺服器「這些爬蟲是友軍」
LiteSpeed 雖然擋得勤快，但我們可以透過 .htaccess 中加入「例外放行」的設定，主動告訴它：Facebook、LINE、Twitter 這些社群爬蟲是「友軍」，好讓各家社群機器人能通過防盜連檢查。
步驟 1：打開你的 .htaccess 設定檔(以使用Hostinger為例)
任何要進入後台修改資料前，請務必先進行備份，以防萬一修改錯誤。
- 登入 Hostinger 後台（hPanel）
- 左側選單點選「網站」→ 選擇你要修改的網站 → 點「管理」
- 往下滑到中間區塊，找到並點選【檔案管理器】（File Manager）
- 進入
public_html或你的網站資料夾 （ 如yanshoto.com） - 找到檔案名稱為
.htaccess的檔案。 - 點右鍵 → 選擇「編輯」或使用內建文字編輯器開啟檔案內容
步驟 2：貼上例外放行的程式碼到 .htaccess 內容（可取代或合併）
這份程式碼是我和 ChatGPT 來回討論後修正整理的版本，除了處理縮圖抓取問題，也額外加強了圖片格式標示與基本的安全性設定。
其中在「防止圖片防盜連」那段規則裡，有一行是針對自己網站網址的判斷條件，像這樣：
RewriteCond %{HTTP_REFERER} !^https://(www.)?你的網址.com/ [NC]
請務必將這裡的網址換成你自己網站的網域名稱，否則會造成規則誤判，直接把自家網站的圖片請求也一起擋掉，如此一來不只會造成縮圖無法顯示，嚴重時甚至會導致整個網站的圖片都無法載入。所以如果你忘了改這段網址，在說這份程式碼「沒用」之前，恐怕得先面對的是自家網站圖片全數消失的災難。
# 正確指定圖片Content-Type
<IfModule mod_mime.c>
AddType image/jpeg .jpg .jpeg
AddType image/png .png
AddType image/gif .gif
AddType image/webp .webp
</IfModule>
# 允許社群爬蟲抓圖，不被LiteSpeed誤擋
<IfModule LiteSpeed>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !(facebookexternalhit|Facebot|Twitterbot|LinkedInBot|Slackbot|Pinterest|WhatsApp|TelegramBot) [NC]
RewriteRule .* – [E=Cache-Control:vary=User-Agent]
</IfModule>
# 防止圖片防盜連（但允許Google/Facebook等抓取）
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?yanshoto(替換成你的網站)\.com/ [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !facebook\. [NC]
RewriteCond %{HTTP_REFERER} !twitter\. [NC]
RewriteCond %{HTTP_REFERER} !pinterest\. [NC]
RewriteCond %{HTTP_REFERER} !bing\. [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ – [NC,F,L]
# 強制https
<IfModule mod_rewrite.c>
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# 安全性加強
<IfModule mod_headers.c>
Header set X-Content-Type-Options “nosniff”
Header set X-XSS-Protection “1; mode=block”
Header always set Referrer-Policy “strict-origin-when-cross-origin”
</IfModule>
步驟 3：儲存後務必清除快取！
改完 .htaccess 之後，請務必：
- 回到 WordPress 後台 → LiteSpeed Cache → 工具 → 按【清除全部快取】
- 如果有使用 Cloudflare → 也去清除快取（Purge Everything）
一定要優先清除你自己網站上安裝的快取外掛（例如 LiteSpeed Cache、WP Rocket 等），這一步其實才是最重要的，因為它才是掌握「你網站實際輸出的 HTML 結構」的源頭。簡單說，它決定了瀏覽器與社群平台讀到的內容是「舊的」還是「新的」，如果你沒有先清掉這一層快取，修改的程式碼根本不會被載入，網站看起來什麼都沒變。
我自己就是犯了這個錯，只清了第二層的 Cloudflare 的 CDN 快取，這層比較偏向圖片、CSS、JS 的靜態資源方面，跟源頭關係不大。只專注眼前，卻跳過了先清網站本身的快取這步驟，結果看起來網站好像已經更新，其實 HTML 裡的 OGP 設定完全沒變，就這樣，我又多繞了兩天的彎路，才終於發現根本問題出在源頭沒有更新。
清完之後社群貼文縮圖不見的問題，立即解決了，當下我都想砸自己腦袋了，這麼基本的概念我居然給忘記了，以前小聚時常被提醒的說。
步驟 4：重新讓社群們去抓圖
再快取清除完畢之後，先執行讓社群重新抓圖的流程，流程如下：
- 前往 Facebook Debugger https://developers.facebook.com/tools/debug/
- 貼上你的文章網址
- 點【Scrape Again（重新抓取）】2 次
這時候，你應該可以在 Facebook Debugger 頁面看到，正確的 og:image 圖片 （ 顯示你文章的縮圖或特色圖片 ）、正確的 og:title 標題 （ 通常是文章標題 ） 和正確的 og:description 描述文字 （ 一般是文章內文摘要或 SEO 描述 ），這三項資訊如果都正確顯示，就表示剛剛修改的程式碼和快取清除流程已經成功生效。
如果還是沒出現縮圖或標題怪怪的，且確定都有清除快取後，那就表示問題可能不是快取或 LiteSpeed 防盜連機制，而是更根本的：
你的 OGP（Open Graph Protocol）根本就沒有設定好，或者沒有正確輸出到 HTML 中
這時請再重新檢查以下幾項：
- SEO 外掛中專門控制「社群分享 / Open Graph」的設定頁，是否已經勾選啟用?
- 單篇文章是否有設好精選圖片？
- 主題是否有正確呼叫
wp_head()？ - 用 Chrome 的開發者工具確認是不是有一堆
meta property="og:..."的標籤，如果沒有，那就是外掛沒輸出，或快取沒清成功。
以上提到的項目，我之後也會陸續撰寫成獨立文章，深入說明它們與縮圖無法顯示之間的關聯，並搭配實際碰到的案例，提供對應的解決方式，因為這些問題我自己也都一一踩過坑，試過解法，算是親身經歷過一輪，想哭。
雖然 Facebook Debugger 是一個非常實用的縮圖除錯工具，但它終究只是結果的呈現窗口，真正的問題還是要回頭從網站本身去查找。只要你按部就班，從 OGP 設定、快取清理、圖片格式與標籤輸出等關鍵環節逐一排查，大多數「社群縮圖無法顯示」的問題其實都能迎刃而解。
小結－自動防盜連機制雖好，但還是得跟它說「友軍是誰」
LiteSpeed 為網站提供了卓越的效能與安全性，尤其在 WordPress 主機市場中已是不可忽視的重要力量。不過，它內建的圖片防盜連機制在保護得太嚴格的情況下，也可能「誤傷友軍」，像是 Facebook、LINE 等社群平台，在抓取縮圖時就經常因此被擋，導致連結預覽異常、縮圖顯示錯誤。
這是因為這些社群平台的爬蟲程式，往往不會附上 Referer 或 User-Agent 等資訊，讓 LiteSpeed 無法判斷來源是否合法，就會將圖片請求當成盜圖行為擋掉，其結果不僅縮圖無法讀取，連帶 OGP 的圖片資訊也會一併失效，讓文章分享出去時看起來破碎、不完整，影響整體點擊率與形象。好在解法並不困難，只要了解原理，在 .htaccess 裡補上一段「放行社群爬蟲」的設定，大多數的抓圖錯誤都能一次解決，不必再一一猜測是哪裡出問題。
這篇筆記整理的是我在 LiteSpeed 環境中實際踩雷後的排查與修正過程。說實話，這類問題在台灣的 WordPress 社群討論中其實很少被提及，當初我也是卡了很久，直到 ChatGPT 一步步協助我除錯，才找到根源，進而解決掉，這才啟發我想寫這系列文的主因之一。
總之，這次伺服器端的圖片防盜與 OGP 抓圖問題算是順利解決了，接下來就輪到其他可能導致縮圖出不來的問題上場，敬請期待下一回合的除 ( 血 ) 錯 ( 淚 ) 筆記。
✦ 喜歡這篇文章嗎？
《煙雲漫筆》的每月慢信會收錄這樣的片段，也會分享一些未公開的草稿與旅行筆記。
如果你也想一起閱讀，歡迎留下信箱。
