# 最近のアップデート後にメールが送信されない **URL:** \ **Category:** Product Support\ **Tags:** email\ **Created:** [2026 年 1 月 16 日午前 3:10 UTC](https://meta.discourse.org/t/mail-does-not-go-out-after-recent-update/393621 "2026-01-16T03:10:17Z")\ **Posts on this page:** 1\ **Showing post:** 20
**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\ **Post date:** [2026 年 1 月 20 日午前 7:04 UTC](https://meta.discourse.org/t/mail-does-not-go-out-after-recent-update/393621/20 "2026-01-20T07:04:43Z")
@supermathie の説明は的確です 👍 タイミングの違いはノイズではなく、実際には有用なシグナルです。 現在見えていることを要約すると次のようになります。 - 25/465 がタイムアウト → サイレントドロップ（Hetzner のポリシーレベルでのブロック、想定内） - 2525 が接続後すぐに切断 → TCP パスは問題ないが、リモート側がセッションを終了させている この最後の点が重要な詳細です。 なぜなら： - TCP ハンドシェイクは成功する - TLS ネゴシエーションは実際には始まらない - そして即座に発生する …これは、Discourse、Sidekiq、Ruby ではなく、Mailgun が接続を早期に拒否していることを強く示唆しています。 これは、最近確認されたいくつかの事柄と一致します。 - IP の評判/地域ベースのフィルタリング - まだ信頼されていない新しい Hetzner の IP 範囲 - または SMTP バナー交換前の Mailgun 側のポリシーチェック Discourse 内の何かが、即座にリモートソケットを閉じるようなことを引き起こすことはありません。Sidekiq はメッセージを `Net::SMTP` に渡して待機するだけです。 後でさらに強力な確認が必要な場合は（全く急ぐ必要はありません）： ```plaintext openssl s_client -connect smtp.gmail.com:587 -starttls smtp ``` 適切な SMTP バナーが表示され、その後認証エラーになるはずです。これは、送信 SMTP 自体は問題なく、Mailgun だけが異なる動作をしていることをほぼ証明します。 * * * そして、特に現在の状況を考えると、一時停止することについては完全に理解しています。 他のすべてのことに加えて、それに対処していることをお見舞い申し上げます ❤ Mailgun から何か有用な情報が得られれば良いのですが、正直なところ、SMTP の評判修正を待つよりも、新規開始またはプロバイダーの切り替え（Brevo、Postmark など）の方が速いことが多いです。 あなたはすでにこれを完全に正しい方法でデバッグしています。ここで何かを見落としたり、Discourse を誤って設定したりしたことを示すものは何もありません。 ドイツへの安全なご旅行と、お体を大切にしてください。 --- _[View the full topic](https://meta.discourse.org/t/mail-does-not-go-out-after-recent-update/393621)._