追記ですが、SWELLのキャッシュ設定です。

念のため「内部リンクのブログカードをキャッシュする」「外部リンクのブログカードをキャッシュする」のチェックを外して保存して確認してみましたが、504が返ってくる状態から改善されませんでした。
現在はスクリーンショットの設定に戻しています。

連投で申し訳ありません。

PHP-FPMを1分ごとに再起動する設定にしましたので、URLにアクセスいただいても問題ございません。
URLにアクセスしてダウンしても1分後には復旧するようにしています。
※アクセスしたタイミングとPHP-FPMの再起動のタイミングが重なると502が返ってきます。ご了承ください

サーバー構築経験をお持ちの様ですので、例えば同じ環境をレンサバかローカルに再現した時にどうなるか？の結果を共有してください。後はPHP7.4にしたらどうなるか？の情報もほしいです。

本題とは異なりますが、

内部リンクで「あわせて読みたい」の文字を消す場合は、

.-internal .p-blogCard__caption {
display:none;
}

で消せます。

「あわせて読みたい」のテキストは関連記事ブロックを選択した状態で右側の設定画面「キャプション」で変えられます。

デザインが異なるのが微妙であれば、SWELL設定＞エディター設定＞その他から、ブログカードのデザインが変えられます。

また、内部リンク用の「チェック」のアイコンが微妙であれば、追加CSSに

.p-blogCard__caption::before {
content: "\e91a";
}

を挿入すれば、外部リンクと同じアイコンに変えられます。

色々追加で調査してみたのですが、結論から言うと原因が分かりませんでした。
内部的にタイムアウトエラーが発生していることは分かったのですが、サーバーの問題なのかネットワークの問題なのかプログラムの問題なのか切り分けが困難で、分かりかねる状態であったためです。

一旦、データベースの中身を手動で書き換えて問題のブログカードを削除し、しらこさんにご提供いただいた情報を参考に、「自サイトの記事を紹介する場合は内部リンクを使用する」という方向で本件はクローズとさせてください。
次の投稿でエラーの詳細を記載しますが、内容から推察するに、内部リンクを使用した場合は不具合が発生しないことが分かっていますので、今後はこの方法を使用する方向です。

skillsharejpさん、しらこさん、ありがとうございました！

今後、他の方の環境で同様の問題が発生した場合のため、私の調査の経緯を記載しておきます。

まずはMariaDBでwp_postsテーブルを見てみました。

問題がある記事のデータ（抜粋）

<!-- wp:loos/step -->
<div class="swell-block-step" data-num-style="circle"><!-- wp:loos/step-item {"stepLabel":"STEP","theLabel":"Vol."} -->
<div class="swell-block-step__item"><div class="swell-block-step__number u-bg-main"><span class="__label">Vol.</span></div><div class="swell-block-step__title u-fz-l">セットアップ編</div><div class="swell-block-step__body"><!-- wp:loos/post-link {"externalUrl":"https://otogeworks.com/blog/setup-wordpress-server-vps/"} /--></div></div>
<!-- /wp:loos/step-item -->

<!-- wp:loos/step-item {"stepLabel":"STEP","theLabel":"Vol."} -->
<div class="swell-block-step__item"><div class="swell-block-step__number u-bg-main"><span class="__label">Vol.</span></div><div class="swell-block-step__title u-fz-l">セキュリティ編</div><div class="swell-block-step__body"><!-- wp:loos/post-link {"externalUrl":"https://otogeworks.com/blog/security-wordpress-server-vps/"} /--></div></div>
<!-- /wp:loos/step-item -->

<!-- wp:loos/step-item {"stepLabel":"STEP","theLabel":"Vol."} -->
<div class="swell-block-step__item"><div class="swell-block-step__number u-bg-main"><span class="__label">Vol.</span></div><div class="swell-block-step__title u-fz-l">チューニング編</div><div class="swell-block-step__body"><!-- wp:paragraph -->

問題がない記事のデータ（抜粋）

<!-- wp:paragraph -->
<p>外部リンクで関連記事を設定</p>
<!-- /wp:paragraph -->

<!-- wp:loos/post-link {"externalUrl":"https://otogeworks.com/blog/debounce-in-a-microcomputer/"} /-->                                               | テストページ       |              | publish     | closed         | closed      |      

ブログカード部分と思わしき記述を比較しても、特に問題がなさそうです。

<!-- wp:loos/post-link {"externalUrl":"https://otogeworks.com/blog/setup-wordpress-server-vps/"} /-->
<!-- wp:loos/post-link {"externalUrl":"https://otogeworks.com/blog/debounce-in-a-microcomputer/"} /-->

この時点で「関連記事ブロックが壊れている状態なので不具合が発生している」という状態ではないと判断しました。

次に「wp:loos/post-link」の記述を頼りにSWELLのソースコードを検索しました。
「swell\classes\Utility\Get.php」のget_external_blog_card関数に辿りつき、「表示できた場合はURLだけが表示される」という事象から、以下の記述で問題が発生していると判断しました。

// Get_OGP_InWP の読み込み
require_once T_DIRE . '/classes/plugins/get_ogp_inwp.php';

$ogps = \Get_OGP_InWP::get( $url );
if ( empty( $ogps ) ) return $url;

get_external_blog_card関数においてURLをreturnする処理は上記のみであり、他はブログカードを生成した状態の文字列を返却するプログラムになっているように見受けられます。
つまりこの辺の処理でコケている可能性が高かったため、「Get_OGP_InWP::get( $url );」でOGP画像（？）を取得する処理で問題が発生していると判断しました。

Get_OGP_InWP::getの中身は「swell\classes\plugins\get_ogp_inwp.php」にあり、get関数の中で呼ばれているfetch関数にerror_log();を付けてデバッグしました。
（適当ですがご容赦ください）

public static function fetch( $url, $args ) {

        $response = wp_remote_get( $url, $args );
        error_log(print_r($url,true));
        error_log(print_r($args,true));
        error_log(print_r($response,true));
        if ( is_wp_error( $response ) ) {
                return false;
        }
        return $response['body'];
}

すると、Nginxのerror.logに以下が出力されました。

2021/11/15 15:24:47 [error] 5975#5975: *154 FastCGI sent in stderr: "PHP message:  https://otogeworks.com/blog/security-wordpress-server-vps/PHP  message: Array
(
    [timeout] => 15
    [redirection] => 3
    [sslverify] =>
)
PHP message: WP_Error Object
(
    [errors] => Array
        (
            [http_request_failed] => Array
                (
                    [0] => cURL error 28: Operation timed out after 15001 milliseconds with 0 bytes received
                )

        )

    [error_data] => Array
        (
        )

    [additional_data:protected] => Array
        (
        )

)" while reading response header from upstream, client: 2406:da14:2c4:b300:bc9e:dfe0:828a:2f31, server: otogeworks.com, request: "GET /blog/tuning-wordpress-server-vps/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php-fpm.sock:", host: "otogeworks.com", referrer: "https://otogeworks.com/blog/tuning-wordpress-server-vps/"

ということで、cURLでタイムアウトエラーが発生しているというのがエラーの内容です。
もしかすると同プログラムにある$default_fetch_args変数のパラメータを変更すると表示されたのかもしれませんが、私が使用しているWordPressサーバーはそれなりに速い環境なので、接続に15秒以上もかかってしまう時点で異常事態と考えています。
（ちなみに$default_fetch_argsのsslverifyのfalseをtrueに書き換えてみたりはしたのですが、改善しませんでした）

他のブログカードでは問題が発生しないことからDNSなどの問題ではないと思うのですが、不具合を起こした原因がOSのライブラリのバージョンや設定、使用しているネットワーク絡みなど可能性が多岐に渡ってしまうため、調査が困難であると結論付けました。

なおcURLでの問い合わせが発生するのは外部リンクだからであり、内部リンクの場合はデータベースから直接データを引っ張ってくる処理になっていることを確認しております。（ソースコードを流し読みしたので誤っているかもしれません）
つまり「内部リンクの場合は上記のエラーが発生しない」ということになります。
（個人的には、しらこさんの情報で「あわせて読みたい」のテキストが変えられることが分かったのが大きいです）

始まりから終わりまで長々と申し訳ありませんが、以上です。
ありがとうございました。

@ushui 詳しくありがとうございます。そして、私が余談のように書いたのがお役に立てられて良かったです。

本件について、私が先程のように「内部リンクを外部リンクと同等に見せる方法」を提示したのは、少なくとも、VPSで構築された環境に起因するか、内部リンクに対して外部リンクを選択していることが原因かどうかを切り分けしたかったからです。
ただ、おそらくですが、VPS上で構築された環境に起因する話ではないかもしれないとは、なんとなくですが予想はしていました。

したがって、後者が原因となる場合には「安心して内部リンクを使えるようにすれば良いことではないか」という観点で書かせていただいた次第です。
ただ、欠点としては、「あわせて読みたい」のテキストは毎回変える必要はありますけどね^^;
あと、外部リンクとは異なり別タブで開かない点を解消したい場合には、それは以前ここでよく投稿してくださっている、かんたさん https://u.swell-theme.com/community/postid/9256/ の回答で解消できると思います。

後日、フォーラム上だけではなく、手前で管理しているサイト上でも記事に残して他の方にも役立てたいと思います（回答が溜まってくると、時々「探しにくい」という声をいただくので）。

私はソースコードの細かい部分は見ていませんが、おそらくですが現状では詳しくご報告いただいたのを参考にすると、「内部リンクに対して外部リンクのブログカードを多用すべきではない」が結論なのかもしれませんね。

まだ詳しく調べられてないですが、性能がいいのにタイムアウトするということは内部リンク先でさらに内部リンクを呼び出しているなどして多重に呼び出しが発生しているのかもしれません...。

しらこさん

私の込み入った情報から、外部リンクを使いたいというわけではない質問者であるところをピックアップしてアドバイスいただいたことに感謝いたします。
ドンピシャの観点でした。

内部リンクという機能がある以上、外部リンクに自サイトを記入する行為が比較的イレギュラーな操作であることは自明です。
記事の表示速度的な観点からも、内部リンクで事足りるなら内部リンクにすべきですね。
該当の記事もすべて内部リンクに修正しました。

了さん

了さんのレスでハッとしたので、以下の手順で試したところ、問題が再現しました。

1. ページA、B、Cを作成する。
2. ページAからB、Cを関連記事ブロックで外部リンクに設定する。
3. ページBからA、Cを関連記事ブロックで外部リンクに設定する。
4. ページCでも同様に設定する。
5. 「キャッシュクリア (ブログカード)」を実施する。
6. ページA～Cのいずれかのページにアクセスするとサーバーがダウンする。

上記は落ちてもいいサーバーでお試しください。

ご明察の通り、恐らく無限リダイレクトループのような現象が発生するのではないかと思います。
無限ではなく上限がある可能性はありますが、私が使用しているサーバーはシングルコア環境なので、異常な多数同時接続を受けた時点でNginxのバックエンドにあるPHP-FPMがリクエストを捌ききれず、ダウンしてしまったというのが真相なのかもしれません。

内部リンクを使用すればそもそも問題は起きないのでレアケースと存じますが、もし上記をレンタルサーバー環境でやってしまった場合、他の利用者に迷惑をかけてしまう可能性はあります。
（超絶レアケースとしては、自分側と相手側がお互いSWELLで、自分が外部リンクを貼ったとき、相手側も自分に対して外部リンクを貼っていた場合、お互いが力尽きるまで戦うDoS攻撃戦争が勃発する？）

私はVPSなので、その点ではある意味心配無用でした。
色々迷走してしまいましてすみません。

（超絶レアケースとしては、自分側と相手側がお互いSWELLで、自分が外部リンクを貼ったとき、相手側も自分に対して外部リンクを貼っていた場合、お互いが力尽きるまで戦うDoS攻撃戦争が勃発する？）

もしこうなるのであればヤバいですね...。ちょっと調べてみます。

やはり相互にブログカードを設置していて、お互いにキャッシュ機能をオフにしている場合は429 Too Many Requestsエラーになっちゃいました！

timeout設定しているので、DoS攻撃ほどヤバいことにはならないっぽいですが...。

一応SWELLのブログカードリクエストでアクセスされている時はSWELLのブログカード化機能をオフにするような形で無限ループを回避できそうです。

対策可能とのことでよかったです！
（了さんには申し訳ないのですが、コーディング中には気づきづらく、かつ面白い類の不具合だと思ってしまいました）

VPSに自分でWordPressを構築している手前、初めに事象に遭遇した時はこちら側の設定が原因である可能性も捨てきれず、切り分けが困難だったので解決できないかもしれないと内心思っていました。
根本まで調査いただきありがとうございます。

2.5.5.2で調整入れてみましたので、もしよければアップデート後に再度テストしてみていただければ助かります！

SWELL 2.5.5.2にて修正されたことを確認しました！
再現手順を実施し、ページを開けること、編集画面を開けることの両方を確認済みです。

安心してブログカードを使えそうです。
迅速なご対応をありがとうございました！

@loos_ryo さん、修正していただきありがとうございます。
@ushui さん、この事象について辛抱強く、詳細な報告と動作確認していただきありがとうございます。

一点、内部リンクで別タブで開く場合には、SWELLにその設定画面がありましたのでその点訂正しておきます。以下の部分です（内部リンクの個別の設定画面にあります）。もしかしたら必要ないかもしれませんが、参考まで。

私は今回の回答を元に、フォーラムだけではなく（時々、探しにくいという声があるので）、非公式でブログカードのカスタマイズ記事を作成してみました。
https://tecchan.jp/swell-tips/entry/blogcard/
今後、カスタマイズ記事が増えていく際には、ユーザーにベネフィットを与えられやすいように、探しやすくするよう考慮しようと思います。

しらこさん

別タブ設定も可能だったのですね。ありがとうございます。
別タブで開かせたいケース（読ませたいのは元記事だけど、参考として別記事に飛ばしたいケース）があったので、早速使用させていただきました。
https://otogeworks.com/blog/security-wordpress-server-vps/#index_id19

カスタマイズ記事についても承知しました。
このやり取りで得られた知見を他のユーザーに横展開できれば、私としても本望です。

ご丁寧にありがとうございます…！（そして、役立って良かったです）

あと、関係ないですがVPSをちょうど立てたいと思っていたので、よろしければ記事めちゃめちゃ参考にさせていただきます…！🙏