私の「イチゲブログ」(お名前.comVPS)のリンクを別のWordpressブログ、イチゲブログ別館2階(シンレンタルサーバー )に貼ったところ、通常のブログカードではなく URLとキャプチャ画像だけ が表示される現象が発生しました。
原因が判明したので、調査過程と解決方法をまとめます。
以下はイチゲブログ別館2階(シンレンタルサーバー )の「Markdownでおしゃれスライドを作る!VS Code拡張機能「Marp」の使い方を徹底解説」という記事中のブログカードです。

↓↓↓↓対策後

ちなみに、この対策したらXでもブログカードが表示されるようになりました。
今回、TLS 1.2無効→有効にしたが、Copilotは、こんなことも言っていたので一応書いておきます。
「TLS 1.3のみ有効というのは、セキュリティ的に最も強固な状態です。TLS 1.2が無効でも、TLS 1.3に対応しているクライアント(ブラウザやボット)がほとんどなので、実用上の問題はほぼありません。」
また、シンレンタルサーバー は、無料プランです。今は、移転以外、受付されていません。
ブログカードのしくみ
まず、ブログカードがどのように生成されるかを理解しましょう。
WordPressのCocoonテーマでは、リンクを貼った際に自動的にそのサイトの情報を取得してブログカードを生成します。実は、この処理には2つの異なる仕組みがあります:
1. サーバーサイドでのOGP情報取得
- イチゲブログ別館2階(シンレンタルサーバー
)が直接リンク先のイチゲブログ(お名前.comVPS)にアクセス
- metaタグから「title」「description」「og:image」などのOGP情報を抽出
- PHPのcURLやfile_get_contents()などを使用
- この段階でTLS通信エラーが発生すると情報取得に失敗
2. キャプチャ画像の生成
- 外部サービス(例:WordPress.comのスクリーンショットAPI)を利用
- ブラウザ経由でのアクセスとは別の経路・プロトコルを使用
- TLS 1.2非対応サイトでも画像キャプチャは成功する場合がある
つまり、OGP取得が失敗してもキャプチャ生成は成功することがあり、その場合に「URL+キャプチャ画像だけ」のブログカードが表示されます。
ブログカードがURLとキャプチャ表示になる原因
私のケースの根本原因はTLSプロトコルの互換性にありました。
- イチゲブログ別館2階(シンレンタルサーバー
)がリンク先のイチゲブログ(お名前.comVPS)にアクセスする際、TLS 1.2を要求
- リンク先の「イチゲブログ」(お名前.comVPS)が TLS 1.3のみ対応(TLS 1.2が無効)
この不一致により、OGP取得が失敗していました。
CDN77 TLS Checkerで調査
問題を特定するため、CDN77 TLS Checkerを使用してリンク先サイトのTLS対応状況を調べました。
CDN77 TLS Checkerの使い方は、リンク先のURL(私の場合、イチゲブログ(お名前.comVPS)https://kikuichige.com/)を貼ってtest nowをクリックするだけです。
調査結果:
TLS protocol versions
- TLS 1.3 Enabled
- TLS 1.2 Disabled
- TLS 1.1 (deprecated) Disabled
- TLS 1.0 (deprecated) Disabled
この結果から、私のサイトがTLS 1.2に対応していないことが判明しました。
私のサイトはVPSで自分ですべて設定しているので、中途半端にTLS1.2に対応してない状態になっていました。
これが通信エラーの直接的な原因でした。
Nginxの設定修正で解決(個人的メモ)
私のVPS環境はNginx+Docker構成です。Nginxの設定ファイルを修正することで問題を解決しました。
ここは完全に個人的メモです。
修正前の設定
ssl_protocols TLSv1.2;に記述されていますが、それだけではダメでssl_ciphersに必要なものが足りませんでした。
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers off;
修正後の設定
ssl_prefer_server_ciphers
は、SSL/TLS通信において 暗号スイート(cipher suite)をどちらの側が優先して選ぶか を制御する Nginx の設定ディレクティブです。
ON→ サーバー側の指定を優先して暗号スイートを選択します。OFFでもいいかもしれません。
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
Nginxの設定確認、以下参照
設定変更後、コンテナを再起動:
sudo docker restart waf-nginx
結果確認
修正後、再度CDN77 TLS Checkerで確認:
- TLS 1.3 Enabled
- TLS 1.2 Enabled
TLS 1.2も有効化されたことを確認しました。
WordPressでリンクを貼り直すと、今度は正常にブログカードが生成されるようになりました!
別の原因の調査方法(上級者向け)
WordPressが実際にリンク先サイトにアクセスできるかをテストする方法です。
テストファイルの作成と配置方法
このファイルはWordPressのルートディレクトリ(wp-config.php
と同じフォルダ)に配置する必要があります。
私の場合設置後、lsの結果は以下。wp-load.phpはcardtest.phpから呼び出すのでないとエラーになります。
cardtest.php wp-activate.php wp-config-sample.php wp-includes wp-mail.php xmlrpc.php
index.php wp-admin wp-config.php wp-links-opml.php wp-settings.php
license.txt wp-blog-header.php wp-content wp-load.php wp-signup.php
readme.html wp-comments-post.php wp-cron.php wp-login.php wp-trackback.php
Claudeに聞いた配置例
/public_html/ ← サイトのルートディレクトリ
├── wp-config.php
├── wp-load.php
├── index.php
├── cardtest.php ← ここに配置
├── wp-content/
├── wp-includes/
└── wp-admin/
cardtest.phpの中身。赤線は調べたいサイトに置き換えてください。
<?php
require_once __DIR__ . '/wp-load.php';
$response = wp_remote_get('https://kikuichige.com/31424', array(
'timeout' => 10,
'redirection' => 5,
'user-agent' => 'WordPress/' . get_bloginfo('version') . '; ' . home_url()
));
if (is_wp_error($response)) {
echo "Error: " . $response->get_error_message();
} else {
echo "Status: " . wp_remote_retrieve_response_code($response) . "\n";
echo "Headers:\n";
print_r(wp_remote_retrieve_headers($response));
echo "\nBody:\n";
echo substr(wp_remote_retrieve_body($response), 0, 500);
}
テストの実行
cardtest.phpをブラウザで実行するには
先ほどのディレクトリのindex.phpと同じところにあるので、まずindex.phpを表示させます。
つまりWordpressブログのメインのURLを入力してアクセス。
その後ろに、cardtest.phpを追加してアクセスすればいいです。
https://cf193110.cloudfree.jp/kikuichige/cardtest.php ← 今は、削除してあるので404になります。
(https://cf193110.cloudfree.jp/kikuichige/は記事中で出てきた別館2階と同じサーバーにあるサイトで別館1階で実験してます。)
結果の確認
アクセスして正常な場合、以下のようなレスポンスが返ってきます。
レスポンス例:
Status: 200 Headers: WpOrg\Requests\Utility\CaseInsensitiveDictionary Object ( [data:protected] => Array ( [server] => nginx [date] => Sat, 09 Aug 2025 21:57:22 GMT [content-type] => text/html; charset=UTF-8 [content-length] => 123167 [x-powered-by] => PHP/8.3.23 [link] => Array ( [0] => ; rel="https://api.w.org/" [1] => ; rel="alternate"; title="JSON"; type="application/json" [2] => ; rel=shortlink ) [content-encoding] => gzip [vary] => Accept-Encoding, Cookie [strict-transport-security] => max-age=2592000 [x-frame-options] => SAMEORIGIN [x-content-type-options] => nosniff ) ) Body:
このテストでエラーが発生した場合、以下のような原因が考えられます:(Claude談)
今回の調査で、いろいろAIに聞きましたが、エラーの内容をもとに聞いていくと変な方向に誘導されることが多いので注意してください。
- TLS/SSL関連のエラー: 「SSL certificate problem」「SSL connect error」
- サーバー制限: 「cURL error 6: Could not resolve host」
- PHP設定: 「allow_url_fopen」や「cURL」が無効
- ファイアウォール: 外部への接続がブロックされている
- タイムアウト: サーバーの応答が遅すぎる
よくあるエラーメッセージの例(Claude談)
テスト実行時に表示される可能性があるエラーメッセージと対処法:
- 「SSL certificate problem: unable to get local issuer certificate」 → SSL証明書の問題。TLS設定またはCA証明書の更新が必要
- 「cURL error 6: Could not resolve host」 → DNS解決の問題。サーバーのDNS設定を確認
- 「cURL error 7: Failed to connect to [hostname] port 443」 → ファイアウォールで外部接続がブロックされている
- 「cURL error 35: SSL connect error」 → SSL/TLSプロトコルの互換性問題(今回のケース)
- 「Fatal error: Call to undefined function wp_remote_get()」 →
wp-load.php
が正しく読み込まれていない(ファイル配置場所の問題)

重要なセキュリティ注意事項
- テスト完了後は必ずファイルを削除してください
- このファイルにはWordPressの内部情報が含まれるため、放置は危険です
- 本番環境では実行時間を短くし、すぐに削除することを推奨します
まとめ
ブログカードが正常に表示されない場合、TLSプロトコルの対応状況を確認することが重要です。特に古いサーバー設定のままだと、このような問題が発生しやすくなります。
セキュリティの観点からも、TLS 1.2以上への対応は必須となっているため、この機会にサーバー設定を見直すことをお勧めします。
同じ問題で悩んでいる方の参考になれば幸いです!
イチゲをOFUSEで応援する(御質問でもOKです)Vプリカでのお支払いがおすすめです。
MENTAやってます(ichige)


