トラブルシューティング

よくある質問

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 Administration の新しい設定で再プロビジョニングします。

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

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

Can I rotate the credentials used by the Relay client?

Yes. Generate a new configuration from the Setup instructions page — a new secret is created each time the configuration is generated. Relay limits how many secrets you can generate. If you reach the limit, identify the secret ID in use by your clients — either on the Relay Groups page, or by running relay describe <id> on the client — then delete the unused secrets from the External Applications page by searching for the group ID.

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

新しいバイナリをダウンロードし、 relay restart <id>を実行します。restart コマンドは、更新されたバイナリを検出し、完全な再インストールを必要とせずに変更を適用します。

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

暗号化されたクライアント構成、クラウドから取得したプロキシ構成、およびログ ファイル。アプリケーションデータはディスクに書き込まれません—リレークライアントはメモリ内のトラフィックをストリーミングします。

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

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

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

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

UiPath Administration に新しいエンドポイントを追加しましたが、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: VM のクローン作成または再イメージ化後に一般的 — リレーを再プロビジョニングします。再プロビジョニングは、 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 信頼ストアに追加します

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

このページに記載されている問題や解決策のいずれもシナリオに当てはまらない場合は、サポート バンドル (診断に必要な構成、ログ、システムの詳細を含む圧縮アーカイブ) を収集して、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/2] Relay metadata and configuration... (2 groups)
  [2/2] Relay logs...

✓ 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/	グループごとのリレーログファイル
errors.log	致命的でない収集警告(警告が発生した場合にのみ表示)

除外される内容

除外	理由
client_config	暗号化されたクライアント資格情報が含まれます。
*.key files	AES 暗号化キー (Linux のみ)
シンボリック	バンドルの外部へのパスの到達を防止します。

注:

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