どのようにお手伝いできますか？

ご用件を簡単にお知らせください。メールで返信します。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
トップページへ

HTTPフォールバック

ネットワークがWebSocketをブロックした場合、チャットは通常のHTTPSで自動的に継続します。切り替え条件、強制設定、Content Security Policyとプロキシの要件、問題の解決方法を説明します。

ウィジェットは通常、WebSocket経由でチャットサーバーに接続します。ただし、一部のネットワークでは許可されていません。その場合に使われるのがHTTPフォールバックです。通常のHTTPSリクエストでチャットを継続するため、運営側や訪問者が操作する必要はありません。

HTTPフォールバックとは

WebSocket接続は、次のような環境で失敗することがあります。

HTTPフォールバックでは、ウィジェットはServer-Sent Events（長時間維持されるHTTPSストリーム）でサーバーからのメッセージを受信します。このストリームで何も届かなければ、ロングポーリングに切り替えます。送信にはHTTPS POSTを使用します。どちらの経路もWebSocketと同じメッセージを運びます。訪問者はメッセージを書き、AIアシスタントやオペレーターの返信を受け取れます。また、通常どおり複数のタブで1つの接続を共有します。添付ファイルはもともとHTTPSでアップロードされるため、接続方式に依存しません。

このフォールバックは、Webサイト上のチャットウィジェットに適用されます。オペレーター画面は引き続きWebSocketで接続します。

適用される条件

ウィジェットは、次の場合にHTTPフォールバックを使用します。

切り替えが行われるのは、そのページでまだWebSocket接続が確立していない間だけです。たとえばネットワークの変更によって既存のWebSocket接続が切れた場合は、ウィジェットはWebSocketで再接続します。

フォールバックが有効になると、そのページでは使い続けます。次のページで再び2回の試行を待たなくて済むように、この切り替えを記憶します。同じタブで30分以内に開いたページは、最初からHTTPSで接続します。同時に、ウィジェットは各ページで1回、WebSocketが通るようになったかをバックグラウンドで確認します。通れば、次のページでは再びWebSocketを使用します。現在のページはHTTPフォールバックのままです。

フォールバックを強制する

テスト時やWebSocketが使えないことが分かっている環境では、最初からHTTPフォールバックを有効にできます。最も簡単なのは、ウィジェットのscriptタグにdata-rc-transport="http"属性を付ける方法です。

<script src="https://cdn.reactive.chat/loader.js"
        data-rc-site-key="SITE_KEY"
        data-rc-transport="http"
        async></script>

ウィジェットはドキュメント全体からこの属性を探します。そのため、ウィジェットの起動時にすでにドキュメント内にある要素なら、別の要素に指定しても機能します。

または、ウィジェットのscriptタグより前に、JavaScriptでオプションを設定します。

<script>
  window.ReactiveChatSettings = { transport: 'http' };
</script>
<script src="https://cdn.reactive.chat/loader.js"
        data-rc-site-key="SITE_KEY"
        async></script>

起動後にReactiveChat('boot', { transport: 'http' })を呼び出しても、この設定は変わりません。接続方式はウィジェットの起動時に決まります。

Content Security Policy

Server-Sent Events、ロングポーリング、送信は、チャット接続と同じアドレスを使用します。ただし、wss://の代わりにhttps:// を使います。WebサイトでContent Security Policyを設定している場合は、connect-srcで両方の形式を許可する必要があります。

connect-src 'self' wss://ws.reactive.chat https://ws.reactive.chat

オフラインフォームとファイルのアップロードにもhttps:// アドレスを使用します。独自ドメインを使用する場合は、サブドメインのアドレスを指定します。

connect-src 'self' wss://chat.your-domain.com https://chat.your-domain.com

ポリシー内の他の項目はそのままにします。ほかに許可が必要な項目は、ウィジェットの埋め込みで説明しています。

独自ドメインを使用する場合

Webサイトのサブドメイン経由でチャットを運用している場合、HTTPフォールバックはWebSocketと同じ/rc_wss/パスを使用します。プロキシに追加のパスは不要ですが、このパスの応答をバッファリングせずに転送する必要があります。

アカウントページと独自ドメインのガイドのテンプレートには、これらの設定がすでに含まれています。以前の設定を引き継いでいる場合は、現在のテンプレートと比較してください。

ブラウザーに保存される情報

HTTPSで接続できると、ウィジェットはブラウザーのsessionStorageにrc_httpという項目を作成します。含まれるのは接続時刻だけで、個人データは含まれません。この項目により、後続のページでは30分間、直接HTTPフォールバックに接続します。WebSocketが再び通るようになると、項目を削除します。他のsessionStorageの項目と同じく、遅くともタブを閉じると消えます。一部のプライベートウィンドウなど、sessionStorageが使えない場合は、ページごとにWebSocketから試します。

使用中の経路を確認する

ブラウザーの開発者ツールを開き、「Network」タブに移動します。

「Application」または「Storage」でも、rc_http項目が設定されているか確認できます。

トラブルシューティング

Content Security Policyがhttpsアドレスをブロックする

connect-srcにwss://アドレスしか記載されていないと、ブラウザーはフォールバックのリクエストをブロックします。この場合、ブラウザーのコンソールにhttps://…/rc_wss/h/auf. に関するCSPメッセージが表示されます。WebSocketが通る環境では問題に気付きませんが、WebSocketを使えないネットワークでは接続がまったく確立しません。上記のとおりhttps:// アドレスを追加してください。

プロキシが応答をバッファリングする

経路上のプロキシがストリームをバッファリングすると、Server-Sent Eventsが遅れて届く、まとめて届く、またはまったく届かないことがあります。ウィジェットはストリームの最初のメッセージを5秒待ってから、ロングポーリングに切り替えます。この方法でもチャットは機能しますが、接続の確立に数秒余計にかかります。独自ドメインを使用する場合は、/rc_wss/のバッファリングを無効にしてください（上記参照）。

長時間のリクエストが切断される

ロングポーリングでは、通知する内容がなければ、サーバーは最大25秒間リクエストを開いたままにします。開いているストリームでは、15秒ごとにキープアライブ信号を送ります。それより早くリクエストを中断するファイアウォールやプロキシがあると、ウィジェットは頻繁に再接続することになります。チャットのアドレスへのリクエストを少なくとも30秒間維持できるようにしてください。

チャットがまったく接続しない

WebSocketとHTTPフォールバックの両方が失敗した場合、ウィジェットはバックグラウンドで試行を続けます。訪問者のネットワークからチャットのアドレスにHTTPSで到達できるか、Content Security Policyやフィルターでブロックされていないかを確認してください。

ドキュメントの関連項目

詳しくは、通信：WebSocket、HTTPフォールバック、再接続をご覧ください。すべての章はドキュメントにあります。

最終更新: