負荷分散された環境でこの問題が発生したとおっしゃいましたね。セッションデータを保存するデフォルトの「In Proc」方法を使用していると思います。もしそうなら、私は何が起こっているのか知っていると思います。(議論のために、2つのサーバーを想定しますが、それ以上あっても問題ありません)
ServerA に送信され、セッションが作成されます。これは In Process であるため、ServerB はそれについて何も知りません。最終的に (そして、それがどのように発生するかは、ロード バランサーの設定方法の問題です。スティッキー セッション? Cookie? ラウンド ロビン?) サーバー B に送信されます。そのサーバーは、あなたがすでにセッションを持っていることを知らなかったからです。新しいセッション ID が作成され、新しいセッション ID が与えられます。
では、なぜあなたの正確な再現手順の下でそれが起こっているのでしょうか? 私の推測では、十分な時間と負荷があれば、/page1 から /page2 に移動するだけであることがわかります。繰り返しますが、これはロードバランサーのセットアップ方法によって異なりますが、何かをトリガーするプロトコルを変更していて、プール内の別のサーバーに送信されている可能性があります。
どうすれば修正できますか?
まず、machine.config に同じマシン キーがあることを確認します。アクセスできない場合は、web.config で機能すると思いますが、試していません。
次に、セッション状態を保存する別の方法を設定します。おそらくSql Server、MySql、Postgres、またはどこでも。ドライバーが構築されているので最も簡単な SQL Server がある場合、別のデータストアがある場合は、それを実行するライブラリを構築または検索する必要があります。Postgres を使用してセッション状態を保存するプロジェクトに取り組みました。
サーバーに接続するためのドライバーとしてnpgsqlを使用し、独自に構築してPgsqlSessionProvider:SessionStateStoreProviderBase
接続するのは実際には非常に簡単です
<sessionState mode="Custom" customProvider="PgsqlSessionProvider">
<providers>
<add name="PgsqlSessionProvider" type="My.namespace.PgsqlSessionStateStore" connectionStringName="connectionStringName" writeExceptionsToEventLog="true" />
</providers>
</sessionState>