前提
①リクエスト→②ロードバランサ→③連携先
evictInBackground を設定している
①と②は問題なし。②と③で接続リセットの例外発生
状況整理
このケースは多くの場合「Reactor Netty 側のプールで接続を保持しているが、連携先やロードバランサ側で接続が切断されてしまい、次の利用時に Reset される」ことが原因です。
各設定値の意味（ConnectionProvider）
-
maxIdleTime
プール内で「最後に使ってからどのくらい待てるか」。
→ これを ロードバランサや連携先の Keep-Alive タイムアウトより短くすべき。 -
maxLifeTime
コネクションを作ってからどのくらいで寿命を迎えるか。
→ ロードバランサ側に「コネクションの最大寿命」がある場合はそれより短く。
明確にわからなければ、maxIdleTimeよりは長め、ただし無限にしない。 -
evictInBackground
バックグラウンドで定期的にプール内のコネクションをチェックし、
maxIdleTime/maxLifeTimeを超えているものを削除する間隔。
→ 数秒〜数十秒単位で設定（ロードバランサの keep-alive より短め推奨）。
一般的な設定指針
もしロードバランサや連携先のタイムアウト値がわかるなら、それを基準にします。
例：ロードバランサの Idle Timeout が 60 秒の場合
.maxIdleTime(Duration.ofSeconds(50)) // 相手側より短く
.maxLifeTime(Duration.ofMinutes(5)) // 5分程度でリサイクル
.evictInBackground(Duration.ofSeconds(30)) // 30秒ごとにチェック
-
maxIdleTime< LB/連携先の Idle Timeout -
maxLifeTimeは必須ではないが、長時間保持しすぎないよう設定 -
evictInBackgroundは短めにしないと「切られた接続をプールに保持 → RST」の原因になる
実運用でよくある値
-
AWS ALB / ELB (Idle Timeout 60s)
→maxIdleTime=50s,evictInBackground=30s -
F5 などで Idle Timeout が 300s
→maxIdleTime=240s,evictInBackground=60s -
相手が不明で、RST が多発する場合
→ かなり短めに設定（maxIdleTime=20s,evictInBackground=10s）して切れやすい接続を排除
✅ 結論としては、
ロードバランサ／連携先の Idle Timeout を調べて、その値より短く maxIdleTime を設定し、evictInBackground をその半分くらいの頻度で回すのがベストです。