favicon の更新・キャッシュ問題の調査

Next.js App Router では app/favicon.ico などの特殊ファイルを置くと、HTML head に favicon 用の metadata/link が自動生成される。layout.tsx の metadata.icons でも favicon を明示すると link rel="icon" が重複することがある。favicon URL を1本に統制したい場合は、favicon 実体を public/favicon.ico などの通常静的ファイルとして配置し、metadata.icons から明示的に参照する構成にすると自動生成と競合しにくい。

ブラウザはfaviconをURL単位で極端に強くキャッシュし、Cache-Controlヘッダーを無視することが多い。特に/favicon.icoはlinkタグと無関係にブラウザが直接取得し、貼り付きやすい。

そのため、アイコン差し替え時にキャッシュヘッダーを設定するだけでは、すでにキャッシュ済みの古いアイコンは消えないことがある。確実なのはアイコンURLにバージョンクエリ(例: ?v=2)を付けてURL自体を変えること。差し替えのたびに数値を上げる。

併用パターン:

• ヘッダー(Cache-Control: public, max-age=0, must-revalidate)で今後の再検証を保証(再発防止)
• バージョンクエリでURLを変え、今のキャッシュを即時無効化

CDN/リバースプロキシ経由時はそちらのキャッシュパージも別途必要。

Electron アプリで外部サイトや連携先の favicon 表示が更新されない場合、アプリの起動引数やプロセス情報から user-data-dir を特定し、その配下の Cache/Cache_Data を確認する。macOS の Claude Desktop では ~/Library/Application Support/Claude/Cache/Cache_Data に Google s2 favicons や gstatic faviconV2 のレスポンスが保存されることがある。rg -a -l 'domain|faviconV2|google.com/s2/favicons' <user-data-dir>/Cache/Cache_Data や strings <cache-file> で content-location、expires、cache-control を確認すると、アプリ側ローカルキャッシュなのか外部サービス側キャッシュなのかを切り分けられる。

ブラウザや外部アプリで favicon が更新されない場合、サイト本体の /favicon.ico や manifest アイコンが最新でも、Google の https://www.google.com/s2/favicons?domain=... は t*.gstatic.com にリダイレクトされ、独自の Cache-Control でキャッシュされる。curl -sSL -D headers.txt -o icon.png 'https://www.google.com/s2/favicons?domain=example.com&sz=96' を実行し、レスポンスヘッダーの content-location と cache-control を確認すると、Google がどのアイコン URL を採用しているか、更新待ちなのかを切り分けられる。