トラブルシューティング

Test Cloud での Relay の接続、DNS ルーティング、DDoS 保護に関する既知の問題と、よくある質問への回答。

よくある質問

RelayはDDoS攻撃から保護しますか?

リレードメインは、Cloudflareを介して提供される uipath.comの下の追加のDNSレコードです。DDoS攻撃対策はCloudflareによって処理され、 cloud.uipath.com の保護方法と一致しています。

すべての Relay クライアントを同じリージョンにデプロイする必要がありますか?

いいえ。Relay クライアントは、物理的にデプロイされている場所に関係なく、標準のルーティング レイヤーを介して Relay API に接続します。ただし、特に BYO LLM のようなペイロードが大きいシナリオで最適なパフォーマンスを得るには、Relay クライアントを Test Cloud テナントと同じ地理的リージョンにデプロイします。リージョンをまたぐトンネルを使用すると、リージョン間の往復時間に比例した遅延が加わります。

予想されるレイテンシ

レイテンシとスループットは、ペイロードサイズ、リレーノードとリレーサーバー間の地理的距離、およびリレーノードの容量によって異なります。同一リージョンのデプロイでは、オーバーヘッドが最小限に抑えられます。クロスリージョントンネルは、リージョン間のネットワークラウンドトリップ時間に比例してレイテンシーを追加します。

Relay クライアントが接続を失った場合はどうなりますか?

Relay クライアントは、指数バックオフを使用して自動的に再接続し、20 秒間隔までスケーリングします。バックグラウンド サービスは、クラッシュ時とシステムの再起動時に自動的に再起動します。ネットワークに一時的な問題が発生しても、手動による介入は必要ありません。ネットワーク アプライアンスのアイドル接続タイムアウトが原因で持続的な切断が発生した場合は、プロアクティブ再接続を有効にします。「 Relay クライアントをデプロイする」をご覧ください。

テナントごとに異なる Relay ノードが必要ですか?

いいえ。同じリレー ノードで、複数のテナントのリレー クライアント プロセスを同時に実行できます。

複数のリレー グループを作成する必要があるのはいつですか?

複数のリレー グループは、ネットワーク分離のためにのみ推奨されます。たとえば、ネットワーク 1 に Jira があり、ネットワーク 2 に SAP がある場合、一方に Jira 、もう一方に SAP エンドポイントを持つ 2 つのリレーグループを作成できます。これらのグループのリレー クライアント プロセスは、それぞれのネットワークにアクセスできる 2 つの VM で実行できます。

リレーグループあたりのオンプレミスエンドポイントの数に制限はありますか?

ハード リミットはありません。中程度のトラフィック (エンドポイントあたり 1 秒あたり 1 から 10 件のリクエスト) の場合は、グループあたり最大 50 個のエンドポイントを使用します。トラフィックが少ない場合は、グループあたり最大 100 個のエンドポイントがサポートされます。

同じマシン上で複数の Relay クライアントを実行できますか?

はい。各リレー グループには、独自のバックグラウンド サービス、データ ディレクトリ、およびログ ディレクトリがあります。relay list を使用して、インストールされているすべての Relay クライアントとそのステータスを表示します。relay describe <id> を使用して、特定のリレー クライアントのサービス設定とローカル パスを検査します。

Relayクライアントを別のマシンに移動できますか?

いいえ。資格情報は、マシン固有のキー (Linux では AES-256-GCM、Windows では DPAPI) で暗号化されます。移動するには、古いマシン上の Relay クライアントを削除し、UiPath の管理から新しい設定を使用して新しいマシンに再プロビジョニングします。

Relay クライアントがインストールされている VM を複製するとどうなりますか?

マシン ID が異なるため、複製時に資格情報の復号が失敗します。クローンに対して relay delete <id> --force を実行し、新しい構成で再プロビジョニングします。

Relay クライアントで使用される資格情報をローテーションできますか?

はい。[ セットアップ 手順] ページから新しい構成を生成します。設定が生成されるたびに新しいシークレットが作成されます。Relay では、生成できるシークレットの数が制限されます。制限に達した場合は、[ Relay Groups] ページまたはクライアントで を実行して、クライアントで使用中のシークレット IDrelay describe <id> を特定し、[ 外部アプリケーション] ページでグループ ID を検索して 未使用のシークレットを削除 します。

Relay クライアントのバイナリを更新するにはどうすればよいですか?

新しいアーカイブを抽出し、抽出したディレクトリから relay restart <id> を実行します。restart コマンドは、更新されたバイナリを検出し、完全な再インストールなしで変更を適用します。オンプレミスの Executor が有効化されている場合、抽出されたディレクトリから を実行すると、 も更新 onprem-executor.jar。

Relay クライアントはディスクにどのようなデータを保存しますか?

暗号化されたクライアント構成、クラウドから取得したプロキシ構成、およびログ ファイル。オンプレミスの Executor が有効化されている場合、Relay クライアントには onprem-executor.jar と onprem-executor.logも格納されます。アプリケーション データはディスクに書き込まれません。Relay クライアントと Executor は、メモリ内のトラフィックをストリーミングします。

Relayクライアントのインストール後にプロキシ構成を変更できますか?

はい。プロキシ環境変数を更新し、 relay restart <id> を実行して変更を適用します。

プロキシに資格情報が必要なのに、Relay クライアントが資格情報なしで接続するのはなぜですか?

環境変数がバックグラウンド サービスに渡されていない可能性があります。Linux の場合: sudo -E を使用して再実行するか、 relay restart <id>を実行します。Windows の場合: プロキシをユーザー環境ではなくシステム レベル (HKLM) で設定します。

UiPath の管理でエンドポイントを追加した後、Relay クライアントを再起動する必要がありますか?

いいえ。設定の変更は、転送中の接続を切断することなく、実行中の Relay クライアントに自動的にプッシュされます。新しく追加したエンドポイントが 404を返す場合、プッシュはまだ適用されていません。フォールバックとして relay reload <id> を実行します。

一般的な問題

以下の問題で問題が解決しない場合は、サポート バンドルを入手して UiPath サポートにお問い合わせください。

症状	原因	解決方法
cloud portal unreachable	ファイアウォールがポート 443 をブロックする	送信 HTTPS の送信を許可する cloud.uipath.com:443
authentication failed	資格情報が無効または期限切れです	UiPath Administration の Relay グループからクライアント設定を再生成します
relay server unreachable	ファイアウォールまたはプロキシが永続トンネルをブロックしている	cloud.uipath.com経由で接続する Relay クライアント26.4.2構成では、HTTPS トラフィックと WebSocket のアップグレードを許可します cloud.uipath.com:443。26.4.2より前のリレー クライアント バージョンの場合、リレー ノードからの送信 TLS の<region>-relay.uipath.com:443を許可します
TLS ハンドシェイク エラー、接続のリセット、または初期接続が成功した後に繰り返されるunexpected EOF	TLS インスペクションが信頼できない署名 CA を使用しているか、プロキシが WebSocket のアップグレードをブロックしているか、DLP/IDS アプライアンスがトンネルを中断しています	cloud.uipath.comを介して接続するリレークライアント26.4.2構成の場合、WebSocketのアップグレードでTLSインスペクション署名CAをcloud.uipath.com:443し、リレークライアントが使用するOS信頼ストアにインストールできるようにします。26.4.2より前のバージョンの Relay クライアントの場合は、<region>-relay.uipath.com:443の TLS インスペクションをバイパスするようにプロキシまたはファイアウォールを設定します。目的地に到達できるため、飛行前のチェックに合格します。リレーがトンネルの確立を試みた場合にのみ、ブレークが表示されます
provisioning timed out after 60s	ネットワーク遅延またはプロキシ遅延	接続とプロキシの設定を確認する再試行
maximum number of allowed agents	グループがRelayクライアントの制限に達しました	未使用のRelayクライアントをグループから削除するか、新しいRelayグループを作成します
config input is empty	空の --config 値または空の構成ファイル	構成文字列または構成ファイルが空でないことを確認します
relay is already running	サービスがすでにアクティブなグループの重複するrelay start	relay stop <id>を実行し、次にrelay restart <id>
relay for group "<id>" is already installed as a system service	このグループのリレー クライアントは、マシンに既にインストールされています	「 relay delete <id>」を実行してから再インストールします
ID mismatch 再起動時	構成ファイルが別のグループに属している	リレー ID に正しい構成ファイルを使用していることを確認してください。
credentials: decryption failed	AES キー ファイルが見つからないか破損している (Linux)、または DPAPI ID の変更 (Windows)	Linux: キー ファイルが削除された場合は、リレーを再プロビジョニングします。Windows: リレーを再プロビジョニングします。これは、仮想マシンの複製または再イメージ化後に一般的です。再プロビジョニングするには、 を実行し relay delete <id> から新しい設定で relay start します
削除時に登録解除が失敗する	資格情報が失われたか、クラウド側のオブジェクトが既に削除されている	relay delete <id> --force を使用すると、クラウドの登録解除をスキップできます
host unreachable via proxy	プロキシがターゲットに到達できない	プロキシ URL が正しいことを確認します。プロキシ ログを確認するプロキシがポート 443 への CONNECT を許可することを確認します。
cannot reach proxy	プロキシ アドレスに到達できません	プロキシのホストとポートが正しく、リレー ノードから到達可能であることを確認します
proxy CONNECT rejected (407)	プロキシで認証が必要	プロキシ URL に資格情報を追加します。 http://user:password@proxy:port
プロキシ環境変数が設定されていますが、リレーは直接接続します	環境変数がサービスに渡されない	Linux: sudo -E を使用して再実行するか、 relay restart <id>を実行します。Windows: プロキシをシステム レベル (HKLM) に設定します
リレーの再接続を繰り返す	不安定なネットワークまたはサイレント アイドル接続のタイムアウト	接続を確認します。プロアクティブな再接続の有効化を検討する
リレー クライアントがオンプレミスのエンドポイントに到達できない	リレー クライアント マシンにターゲットへのネットワーク アクセスがありません	リレー ノードがオンプレミスのエンドポイントに直接アクセスできることを確認します。
オンプレミス エンドポイントに接続する TLS エラー	CA 証明書がリレー ノードの OS 信頼ストアによって信頼されていない	発行元 CA 証明書をリレー ノードの OS 信頼ストアに追加します
local error: tls: no renegotiation HTTPS のオンプレミス エンドポイントを呼び出す場合	バックエンド サーバーまたはロード バランサーが、最初のハンドシェイク後に TLS の再ネゴシエーションを要求します	バックエンドで TLS 再ネゴシエーションを無効にするか、TLS 1.3 を使用します。バックエンドを変更できない場合は、 TLS 再ネゴシエーションの一時的な回避策を使用する前に、UiPath サポートに連絡して承認を求めてください。

オンプレミスでの Executor の問題

これらの問題は、オンプレミスの Executor を使用する、サポート対象の TCP ベースの接続に適用されます。

症状	原因	解決方法
java executable not found、サポートされていない Java バージョン、または Java バージョンの確認に失敗しました	サポートされている TCP ベースの接続でオンプレミスの Executor を使用しているが、Java が見つからないか、古すぎるか、Relay サービス アカウントで利用できない	Java 21 以降の JRE または JDK をインストールし、 java がサービス アカウント PATHにあることを確認するか、 を渡します --onprem-executor-java-home <java-home>
bundled on-prem executor runtime was not found next to the relay binary	onprem-executor.jar が見つからないか、判読できないか、有効なJARファイルではない	Relay バイナリと onprem-executor.jar を同じアーカイブから抽出し、サービスの開始時またはアップグレード時にまとめて保管します。relay describe <id>を実行して、報告された Executor のバージョンを確認します
UiPath Relay On-Prem Executor cannot listen on localhost:<port> OR --onprem-executor-listen-port must be between 1 and 65535	設定されたループバック ポートがすでに使用中であるか、有効な TCP ポート範囲外です	--onprem-executor-listen-port <port>を使用して無料のローカル ポートを選択します。既定では です 18080
オンプレミスの Executor は起動するが、TCP ベースの接続は失敗する	Relay ホストがターゲット システムを解決または到達できないか、コネクタ ライブラリが見つからない	onprem-executor.logを確認し、Relay ホストからのターゲットのホスト名とポートへのアクセスを確認し、コネクタ ライブラリが依存関係ディレクトリにあることを確認します
--onprem-executor-dep-dir path is not accessible、must point to a directory、または must not be group- or world-writable	パスが存在しないか、ディレクトリではないか、Linux でグループまたはワールド書き込み可能である	Relay サービス アカウントが読み取ることができ、権限のないユーザーが変更できない、管理者が所有する既存のディレクトリに --onprem-executor-dep-dir を指定します
UnsatisfiedLinkError and libsapjco3.so: cannot open shared object file in the executor log, even though the file is present	The SAP JCo native library does not match the operating system and CPU architecture of the process loading it	Download the SAP Java Connector 3.1 package for the correct platform: the Relay host for a service deployment, or Linux on x86_64 for the container image. Confirm with file libsapjco3.so

TLS 再ネゴシエーションの回避策を一時的に使用してください

Relay は、サーバーが要求した TLS 再ネゴシエーションを既定で無効にします。UiPath サポートが回避策を承認した場合:

1. Relay クライアント サービス環境で UIPATH_RELAY_ALLOW_TLS_RENEGOTIATION=once を設定します。

   Linux システム サービス:sudo systemctl edit relay-<id>.serviceを実行し、 を追加して保存します。

   [Service]
   Environment="UIPATH_RELAY_ALLOW_TLS_RENEGOTIATION=once"
   

   対話型エディターのないホストで、同じブロックを /etc/systemd/system/relay-<id>.service.d/override.conf に記述し、 sudo systemctl daemon-reloadを実行します。

   Linux ユーザー モード サービス:systemctl --user edit relay-<id>.serviceを実行して、同じブロックを追加します。

   Windows: Administrator PowerShell で、以下を実行します。

   [Environment]::SetEnvironmentVariable("UIPATH_RELAY_ALLOW_TLS_RENEGOTIATION", "once", "Machine")
   

2. Relay クライアント サービスを再起動します。

   Linux システム サービス:

   sudo relay restart <id>
   

   Linux ユーザー モード サービス:

   relay restart <id>
   

   systemctl edit コマンドは、オーバーライドを保存した後、ユニット構成を再ロードします。

   Windows:

   .\relay.exe restart <id>
   

   注:

   この値 once では、接続ごとに 1 回の再ネゴシエーションが許可されます。freelyを使用します。これにより、バックエンドで必要と UiPath サポートが判断した場合にのみ、再交渉を繰り返すことができます。

3. バックエンドが更新されたら、環境の設定を削除し、Relay クライアント サービスを再起動します。

   Linux システム サービス:sudo systemctl edit relay-<id>.serviceを実行し、環境の設定を削除してから、手順 2 の Linux システム サービスの再起動コマンドを実行します。

   Linux ユーザー モード サービス:systemctl --user edit relay-<id>.serviceを実行し、環境の設定を削除してから、手順 2 の Linux ユーザー モード再起動コマンドを実行します。

   Windows:

   [Environment]::SetEnvironmentVariable("UIPATH_RELAY_ALLOW_TLS_RENEGOTIATION", $null, "Machine")
   .\relay.exe restart <id>
   

サポート バンドルを収集する

このページで説明している問題や解決策のいずれも自身のシナリオに当てはまらない場合は、診断に必要な設定、ログ、システムの詳細を含む圧縮アーカイブであるサポート バンドルを用意して、UiPath サポートに問題を報告してください。資格情報と暗号化キーは一切含まれません。

# Collect for all relay clients on this machine
relay support-bundle

# Collect for a specific relay client
relay support-bundle <id>

# Write to a specific directory
relay support-bundle --output-dir /path/to/dir

アーカイブは、既定で現在のディレクトリに書き込まれます (Linux では.tar.gz 、Windows では .zip )。アーカイブとその SHA-256 ハッシュを UiPath のサポートと共有します。

出力例:

Collecting support bundle...
  [1/3] Relay metadata and configuration... (2 groups)
  [2/3] Relay logs...
  [3/3] System diagnostics...

✓ Support bundle created: support-bundle-relay01-20260413-150405.tar.gz (3.1 MiB)
  SHA256: a1b2c3d4e5f6789abcdef0123456789abcdef0123456789abcdef0123456789

含まれる機能

ファイル	内容
bundle-info.json	バンドルメタデータ:リレーバージョン、ホスト名、OS、アーキテクチャ、収集時間
relay-version.txt	リレーのバージョン、ビルド日、git commit
relay-list.json	ステータスのこのマシン上のすべてのリレー グループ
groups/<id>/data/	グループごとのメタデータ (metadata.json)
groups/<id>/logs/	グループごとの Relay クライアント ログ (オンプレミスの Executor が有効化されている場合の onprem-executor.log を含む)
groups/<id>/onprem-executor.txt	オンプレミスの Executor のステータスと診断メタデータ (Java とランタイムに関する情報、設定されている依存関係のファイル名とサイズを含む) (オンプレミスの Executor が有効な場合にのみ存在)
errors.log	致命的でない収集警告(警告が発生した場合にのみ表示)

除外される内容

除外	理由
client_config	暗号化されたクライアント資格情報が含まれます。
*.key files	AES 暗号化キー (Linux のみ)
*.jar files	実行時のバイナリと依存関係のバイナリをアーカイブから除外します。代わりに、関連するメタデータが onprem-executor.txt に含まれる
シンボリック	バンドルの外部へのパスの到達を防止します。

注:

Linux： システム サービスとしてインストールされたグループには sudo relay support-bundleが必要です。ユーザー モードのグループでは、そうではありません。コマンドで権限警告のあるグループがスキップされた場合は、 sudoを使用して再実行します。