Implementar el cliente de Relay

Requisitos previos del cliente de Relay, requisitos mínimos y pasos de configuración multiplataforma para conectar tu red local a Test Cloud.

Instala e inicia el cliente de Relay en una máquina de tu red para establecer el túnel saliente a Test Cloud. Antes de comenzar, configura un grupo de Relays y ten lista la cadena de configuración del cliente.

Requisitos previos

Requisitos de hardware

Perfil	vCPU	RAM	Grupos de Relay	Puntos finales por grupo	Use case
Estándar	1	2 GiB	Hasta 10	Hasta 50	La mayoría de las implementaciones
Grande	2	4 GiB	10+	Hasta 50	Entornos de alto rendimiento o a gran escala

Estos son los requisitos mínimos para el cliente de Relay cuando el ejecutor local no está habilitado. Si el host también ejecuta otras cargas de trabajo, añade capacidad para ellas además de estas cifras. Para las implementaciones que habilitan el ejecutor, utiliza las cifras en Planificación de recursos para las conexiones basadas en TCP compatibles .

Planificación de recursos para conexiones basadas en TCP compatibles

Cada grupo de Relay que instale se ejecuta como su propio servicio de cliente de Relay. Con el ejecutor local habilitado, ese servicio inicia y supervisa un proceso Java. Las siguientes cifras son para un solo grupo de Relay con el ejecutor habilitado.

Perfil	vCPU	RAM	RAM reservada para el ejecutor
Estándar (con ejecutor)	2	4 GiB	1 GiB
Grande (con ejecutor)	4 o más	4 GiB o más	1 GiB o más

La RAM incluye la reserva del ejecutor, el sistema operativo y el runtime de Java. Añade capacidad para la supervisión y cualquier otra carga de trabajo en el host. Después de la puesta en marcha, si el uso de la memoria del ejecutor se acerca a su reserva, aumenta la reserva y la RAM juntas.

Consejo:

Para minimizar el uso de recursos, registra todos tus puntos finales basados en TCP en un solo Grupo de Relay. Su cliente de Relay ejecuta un ejecutor local para cada punto final basado en TCP, por lo que reserva memoria, dimensiona el host y supervisa los registros del ejecutor para un solo proceso.

Si los requisitos de segmentación o disponibilidad de tu red requieren más de un Grupo de Relay con el ejecutor en el mismo host:

• Asigna al ejecutor de cada grupo un valor --onprem-executor-listen-port único.
• Reserva otro 1 GiB para cada proceso ejecutor adicional.
• Tamaño de la CPU para el tráfico total en todos los grupos, en lugar de multiplicar la cifra de CPU por grupo por el número de grupos.
• Permitir disco para un JAR de ejecutor independiente y un archivo de registro por grupo.

Requisitos del disco

Perfil	Disco libre mínimo
Estándar (1-10 grupos)	200 MB
Grande (más de 10 grupos)	1 GB

Los mínimos anteriores cubren solo el cliente de Relay. Si habilitas el ejecutor local, permite espacio adicional para el tiempo de ejecución de Java, onprem-executor.jar las bibliotecas del conector que proporcionas y los registros del ejecutor retenidos. El crecimiento del registro depende de tu volumen de tráfico, el nivel de registro y el período de retención configurado.

Sistemas operativos compatibles

Arquitectura	Linux	Ventanas
x86_64 (amd64)	Compatible	Compatible
ARM64 (aarch64)	Compatible	Compatible

Requisitos de red

El cliente de Relay requiere conectividad solo de salida. No se necesitan reglas de firewall entrantes.

Cada versión de cliente de Relay llega a cloud.uipath.com para autenticarse y registrarse. A partir del cliente de Relay 26.4.2, las nuevas configuraciones también llevan el túnel persistente a través de esa misma URL, por lo que ya no necesitan un nombre de host de Relay específico de la región en la lista de permitidos.

Configuración del cliente de Relay	Protocolo	Puerto	Destination	Se requiere paso de TLS	Propósito
Todas las versiones de cliente de Relay	Https	443	cloud.uipath.com	No es necesario	Autenticación y registro de Relay
Cliente de Relay 26.4.2 o posterior	HTTPS/WSS	443	cloud.uipath.com	No es necesario	Túnel persistente
Versiones de cliente de Relay anteriores a 26.4.2	TLS	443	<region>-relay.uipath.com	Obligatorio	Túnel persistente

Las versiones de cliente de Relay anteriores a 26.4.2 siguen funcionando con nombres de host de Relay regionales. Mantenga esos nombres de host en la lista de permitidos hasta que pase al cliente de Relay 26.4.2 o posterior y se conecte a través de cloud.uipath.com.

Para las versiones de cliente de Relay anteriores a 26.4.2, reemplace <region> por la región de su tenant de Test Cloud. Para obtener la lista completa de regiones, consulta Regiones globales en la nube.

Región	Nombre de host del servidor de Relay
EE. UU.	us-relay.uipath.com
UE	eu-relay.uipath.com
Canadá	ca-relay.uipath.com
Suiza	ch-relay.uipath.com
Australia	au-relay.uipath.com
Singapur	sg-relay.uipath.com
Japón	jp-relay.uipath.com
Corea del Sur	kr-relay.uipath.com
EAU	ae-relay.uipath.com
Reino Unido	uk-relay.uipath.com
Unión Europea (región diferida)	gxp-eu-relay.uipath.com
Estados Unidos (región diferida)	gxp-us-relay.uipath.com

Nota:

Ponte en contacto con el soporte de UiPath para confirmar el nombre de host del servidor de retransmisión si la región de tu tenant no aparece en la lista anterior.

Elige la región que coincida con tu región de tenant de UiPath Cloud, no la ubicación física del nodo de Relay. Por ejemplo, si tu tenant está aprovisionado en la región de EE. UU., utiliza us-relay.uipath.com incluso si el propio Relay se ejecuta en una geografía diferente. Las configuraciones del cliente de Relay 26.4.2 que se conectan a través de cloud.uipath.com no utilizan este nombre de host regional.

Consideraciones de latencia: debido a que el tráfico viaja desde UiPath Cloud a través del servidor de retransmisión y el nodo de retransmisión al servicio local, colocar el nodo de retransmisión geográficamente cerca de la región de tu tenant minimiza el tiempo de ida y vuelta y mejora el rendimiento general.

Para las configuraciones del cliente de Relay que se conectan a través 26.4.2 cloud.uipath.com de, configura cortafuegos y proxies para permitir el tráfico HTTPS y las actualizaciones de WebSocket a.cloud.uipath.com:443 Si un proxy inspecciona TLS para cloud.uipath.com, instala la CA de firma del proxy en el almacén de confianza del sistema operativo utilizado por el cliente de Relay y asegúrate de que el proxy permita actualizaciones de WebSocket.

Para las versiones del Cliente de Relay anteriores a 26.4.2, configura tu cortafuegos y cualquier proxy o dispositivo DLP que inspeccione TLS para permitir el paso de TLS para <region>-relay.uipath.com:443; la inspección de TLS en el nombre del host de Relay regional rompe el túnel de Relay.

El host de Relay debe resolver y conectarse a cada punto final HTTP o HTTPS registrado, y al host y puerto de cada punto final basado en TCP compatible.

La ruta de enrutamiento es flexible. Una ruta de red directa, un proxy de salida corporativo o un host de salto son aceptables, siempre que la conexión se realice correctamente desde el host de Relay. Planifique la ubicación para que todos los destinos del grupo permanezcan accesibles.

Ancho de banda

El canal de control (latidos y autenticación) utiliza aproximadamente 1-2 KB/minuto cuando está inactivo. El tráfico de datos escala con el volumen de solicitudes que tus servicios en la nube envían a los puntos finales locales. Para los puntos finales HTTP y HTTPS, el Relay actúa como un túnel transparente, sin sobrecarga adicional más allá de TLS y el marco ligero de WebSocket utilizado para las conexiones cloud.uipath.com.

Para las conexiones basadas en TCP compatibles, el ejecutor local traduce cada solicitud al protocolo del conector. Por lo tanto, el tráfico entre el ejecutor y el sistema de destino refleja ese protocolo en lugar del tamaño de la solicitud original. El tráfico entre el cliente de Relay y el ejecutor permanece en la interfaz de bucle invertido y no sale del host.

Verificar conectividad

Antes de instalar el cliente de Relay, confirme que el tráfico saliente en el puerto 443 está permitido a los destinos necesarios para su configuración.

Linux

nc -zv cloud.uipath.com 443

# Required only for Relay client versions earlier than 26.4.2
nc -zv <region>-relay.uipath.com 443

Windows (PowerShell)

Test-NetConnection -ComputerName cloud.uipath.com -Port 443

# Required only for Relay client versions earlier than 26.4.2
Test-NetConnection -ComputerName <region>-relay.uipath.com -Port 443

Un resultado correcto muestra TcpTestSucceeded : True en Windows y succeeded en Linux. Si una comprobación necesaria falla, revisa las reglas de tu cortafuegos. Para las configuraciones del cliente de Relay 26.4.2 que se conectan a través de cloud.uipath.com, confirma que se permiten las actualizaciones de WebSocket; para las versiones de cliente de Relay anteriores a 26.4.2, confirma que el paso de TLS está configurado para el nombre de host del servidor de Relay.

Ejecutor local para conexiones basadas en TCP compatibles

Para las conexiones basadas en TCP compatibles, como SAP BAPI, las solicitudes las gestiona el ejecutor local, un proceso Java que habla el protocolo del conector y reenvía la llamada al sistema de destino. En las implementaciones de servicios de Linux y Windows, descritas a continuación, el cliente de Relay lo inicia y lo supervisa. En las implementaciones de contenedores, se ejecuta como un contenedor independiente: consulta SAP BAPI y otras conexiones basadas en TCP.

Importante:

La compatibilidad con ejecutores locales requiere el cliente de Relay 26.4.3 o posterior.

El cliente de Relay inicia un proceso ejecutor para cada servicio de cliente de Relay, en las implementaciones de servicio de Linux y Windows. El ejecutor escucha solo en localhost, en el puerto 18080 de forma predeterminada, y no es accesible desde fuera del host. Como cualquier servicio de bucle invertido, otros procesos en el mismo host pueden acceder a él, por lo que trata el acceso local al host de Relay como confidencial.

Antes de habilitarlo:

• Tener disponible un runtime de Java 21 o posterior. Un JRE o JDK es suficiente y una instalación existente funciona. Pon java en el PATH de la cuenta que ejecuta relay start, o pasa la ubicación del runtime con --onprem-executor-java-home.
• Extrae el binario de Relay, relay en Linux o relay.exe en Windows, y el onprem-executor.jar incluido del mismo archivo. Deja los dos archivos juntos en el directorio extraído y ejecuta los comandos de instalación o actualización desde ese directorio.
• Asegúrese de que el host de Relay pueda alcanzar el nombre de host y el puerto del sistema de destino.
• Si un conector requiere bibliotecas que UiPath no incluye, colócalas todas en un directorio duradero que la cuenta de servicio de Relay pueda leer y luego --onprem-executor-dep-dir apúntalo. El cliente de Relay almacena la ruta, pero no copia los archivos.
• Para SAP BAPI, ese directorio contiene los archivos SAP JCo 3 sapjco3.jar y sapidoc3.jar, además de la biblioteca nativa que coincide con el sistema operativo host y la arquitectura de runtime de Java. Utiliza la versión de SAP JCo que SAP admite para tu sistema SAP y el runtime de Java.
• El directorio de dependencias es una ruta de carga de código para el ejecutor, que se ejecuta con los privilegios de la cuenta de servicio de Relay. Debe ser propiedad del administrador y no debe ser modificable por usuarios sin privilegios.
• En Linux, utiliza 0755 para el directorio y 0644 para los archivos. En Windows, colócalo debajo de C:\Program Files, lo que otorga a los administradores acceso de escritura y a otras cuentas de lectura y ejecución de forma predeterminada.

Para ver los comandos de instalación y verificación copiables, consulta Linux o Windows. Después de la instalación, relay describe <id> informa si el ejecutor está habilitado y qué directorio de inicio y dependencias de Java utiliza.

Importante:

En una implementación de contenedor, el cliente de Relay no inicia el ejecutor, por lo que los requisitos del runtime de Java y del directorio de dependencias para las implementaciones de servicio no se aplican, y --onprem-executor-java-home y --onprem-executor-dep-dir no tienen efecto. Ejecuta el ejecutor como un contenedor independiente en su lugar, como se describe en SAP BAPI y otras conexiones basadas en TCP.

Configurar un proxy (si corresponde)

Si tu red enruta el tráfico saliente a través de un proxy, establece las siguientes variables de entorno antes de ejecutar relay start. El cliente de Relay utiliza esta configuración para el tráfico saliente con reconocimiento de proxy.

Variable	Propósito
HTTPS_PROXY / https_proxy	URL de proxy (marcada en primer lugar)
HTTP_PROXY / http_proxy	URL de proxy (alternativa)
NO_PROXY / no_proxy	Hosts o dominios separados por comas que omiten el proxy

La URL del proxy debe utilizar uno de estos esquemas: http://, https://, socks5:// o ntlm://. Formato: scheme://[user:password@]host:port.

Para https:// : el cliente de Relay valida el certificado TLS del proxy con el almacén de confianza del sistema operativo. Si tu proxy utiliza una CA corporativa o autofirmada, añade esa CA al almacén de confianza de la máquina cliente de Relay antes de iniciar el Relay; de lo contrario, el protocolo de enlace TLS falla con un error de verificación de certificado.

Para las configuraciones del cliente de Relay 26.4.2 que se conectan a través de cloud.uipath.com, configura tu proxy para permitir conexiones HTTPS de larga duración y actualizaciones de WebSocket a cloud.uipath.com:443. Si el proxy inspecciona TLS para cloud.uipath.com, instala la CA de firma del proxy en el almacén de confianza del sistema operativo utilizado por el cliente de Relay.

Para las versiones de cliente de Relay anteriores a 26.4.2, configure su proxy para omitir la inspección TLS para <region>-relay.uipath.com:443. Los archivos PAC, la detección automática de WPAD y el encadenamiento de proxy no son compatibles. Establece la URL del proxy explícitamente. Cuando se detecta un proxy, las comprobaciones de requisitos previos muestran via proxy en la salida.

Importante:

El cliente de Relay redacta las contraseñas de proxy en los registros. Sin embargo, las credenciales establecidas en las variables de entorno pueden ser visibles en los listados de procesos y los archivos de unidad systemd. Utiliza credenciales de servicio dedicadas y restringe el acceso al nodo de Relay en consecuencia.

Configurar IP de confianza (si corresponde)

Si tu organización restringe el acceso por dirección IP, entra en Administración de UiPath y añade la IP NAT de la máquina que ejecuta el cliente de Relay a la lista de IP de confianza. El tráfico saliente del cliente de Relay llega a Test Cloud desde esta dirección IP, por lo que debe estar permitido explícitamente.

Para obtener instrucciones, consulta Añadir rangos de IP de confianza.

Aceptar el acuerdo de licencia

Antes de iniciar el cliente de Relay, debe aceptar el acuerdo de licencia. Elige uno de los siguientes métodos:

Opción 1 (variable de entorno). Establece la variable de entorno LICENSE_AGREEMENT para aceptar:

Linux

export LICENSE_AGREEMENT=accept

Ventanas

$env:LICENSE_AGREEMENT=accept

Opción 2 (parámetro en línea). Anexa --accept-license-agreement al comando relay start:

./relay start --config "<your-config>" --accept-license-agreement

Guías de configuración

Para las implementaciones de producción, consulta la guía de la plataforma para tu sistema operativo. Abarca los comandos de inicio rápido, la estructura de directorios, la gestión de servicios, la configuración del marco de seguridad y los procedimientos de desinstalación:

Plataforma	Guía
Linux	Implementar el cliente de Relay en Linux
Ventanas	Implementar el cliente de Relay en Windows
Contenedor	Implementar el cliente de Relay como contenedor

Operaciones

Resiliencia de la conexión

El cliente de Relay mantiene el túnel automáticamente:

• Latidos cada 30 segundos de forma predeterminada (configurable a través de --heartbeat-interval, mínimo 10 segundos). El tiempo de espera del túnel es 3 veces el intervalo de latido. Reduce el intervalo si tu cortafuegos, proxy o NAT descarta las conexiones TCP inactivas antes de 30 segundos:

  relay start --config "<config>" --heartbeat-interval 10 --accept-license-agreement
  relay restart <id> --heartbeat-interval 10
  

• Reconectarse automáticamente al desconectarse, utilizando la escala de retroceso exponencial a intervalos de 20 segundos.
• Reinicio automático del servicio si el proceso falla, gestionado por systemd en Linux y el Gestor de control de servicios de Windows en Windows.
• Servicio de inicio automático al reiniciar el sistema.

Reconexión proactiva

Las redes detrás de un proxy corporativo, un equilibrador de carga o un cortafuegos con un tiempo de espera de conexión inactiva pueden finalizar de forma silenciosa las conexiones TLS de larga duración. La reconexión proactiva restablece la conexión de control en una programación fija para evitarlo.

Habilítelo con el marcador --reconnect-interval :

relay start --config "<config>" --reconnect-interval 1800 --accept-license-agreement

El mínimo efectivo es de 1800 segundos (30 minutos). Establece el intervalo en aproximadamente la mitad del tiempo de espera de inactividad de tu dispositivo de red, por ejemplo, 1800 segundos para un tiempo de espera del cortafuegos de 60 minutos. Dejar deshabilitado en redes estables sin un tiempo de espera de conexión inactiva.

• Drenaje elegante. Cuando transcurre el intervalo, el cliente de Relay deja de aceptar nuevos trabajos y espera a que se completen las conexiones en tránsito, hasta un tiempo de espera de drenaje de 300 segundos, antes de cerrar la conexión antigua y abrir una nueva. Las solicitudes que aún estén en vuelo cuando se alcance el tiempo de espera de drenaje se cancelarán.

• Alta disponibilidad. Cuando se implementan varios clientes de Relay en el mismo grupo, se coordinan para que solo se agote un cliente a la vez. El grupo continúa sirviendo tráfico a lo largo de cada ciclo de reconexión.

• Señales de que se necesita una reconexión proactiva: los registros muestran errores unexpected EOF periódicos o desconexiones silenciosas a pesar de una red subyacente estable, normalmente causadas por un tiempo de inactividad de 30 a 60 minutos en un firewall, proxy o equilibrador de carga.

Volver a cargar la configuración

relay reload <id>

Vuelve a recuperar la configuración de proxy de Test Cloud y la aplica sin reiniciar. Los cambios en la nube, como nuevos puntos finales o rutas de comprobación de estado actualizadas, se envían automáticamente a un cliente de Relay en ejecución y normalmente no requieren una recarga. Utiliza este comando como alternativa solo si un punto final recién añadido devuelve 404.

Registro

Configuración	Valor
Nivel predeterminado	info
Rotación	Diario
Retención	7 días
archivo de registro .etl	relay.log (actual), relay.YYYYMMDD-HHMMSS.log (rotado)

Anula el nivel de registro predeterminado con --log-level trace/debug/info/warn/error. En el cliente de Relay 26.4.2 o posterior, anule la retención de registros rotados con --log-retention-days <days> en relay start o relay restart; la retención mínima es de 7 días.

Referencia de los comandos

Inicio de relé

Aprovisione un nuevo cliente de Relay e inícielo como servicio en segundo plano.

Acuerdo de licencia (se requiere uno)

• --accept-license-agreement: acepta el acuerdo de licencia de usuario final en línea.
• LICENSE_AGREEMENT=accept: variable de entorno equivalente al marcador. relay start imprime el EULA y sale si no se establece ninguno.

Configuración (se requiere una)

• -c, --config <string>: cadena de configuración codificada en base64 en línea.
• --config-file <path>: ruta a un archivo que contiene la cadena de configuración. Recomendado: mantiene el secreto fuera del historial de shell.

Ajuste (opcional)

• --heartbeat-interval <sec>: intervalo de latido del túnel. Predeterminado 30. Mínimo 10. El tiempo de espera del túnel es 3 veces este valor. Baje si su firewall, NAT o proxy descarta el TCP inactivo antes de 30 segundos.
• --reconnect-interval <sec>: intervalo de reconexión proactiva. Predeterminado 0 (deshabilitado); mínimo efectivo 1800 (30 minutos) cuando se establece.
• --log-level <level>: trace, debug, info, warn o error. Predeterminado info.
• --log-retention-days <days>: número de días para conservar los archivos de registro rotados. Predeterminado 7. Mínimo 7. Requiere el cliente de Relay 26.4.2 o posterior.
• -d, --detach=false: se ejecuta en primer plano en lugar de como un servicio en segundo plano. Útil para depurar incidencias de inicio.

Ejecutor local (opcional)

• --enable-onprem-executor: habilita el ejecutor local. En las implementaciones de servicios de Linux y Windows, el cliente de Relay inicia el proceso del ejecutor incluido. En una implementación de contenedor, se conecta al contenedor ejecutor en el puerto predeterminado 18080.
• --onprem-executor-listen-port <port>: puerto en el que escucha el ejecutor local. Predeterminado 18080. En una implementación de contenedor, utiliza el valor SERVER_PORT del contenedor ejecutor. Este marcador por sí solo también habilita el ejecutor.
• --onprem-executor-java-home <path>: JAVA_HOME utilizado para ejecutar el ejecutor local. Si se omite, java se resuelve desde PATH. Sin efecto en una implementación de contenedor.
• --onprem-executor-dep-dir <path>: único directorio que contiene todas las dependencias del conector, tanto los JAR como las bibliotecas nativas del sistema operativo correspondientes. Para SAP BAPI, es decir, sapjco3.jar, sapidoc3.jar, y la biblioteca nativa de SAP JCo para el host. Sin efecto en una implementación de contenedor, donde la imagen del ejecutor es propietaria de esta ruta.

La dirección del ejecutor se fija en localhost. El nivel de registro de Relay y la configuración de retención también se aplican a onprem-executor.log.

Rutas de instalación no predeterminadas (opcional)

• --data-dir <path>: directorio de configuración.
• --logs-dir <path>: directorio de archivos de registro.
• --bin-dir <path>: directorio de instalación binario.

Solo Linux

• --user-mode: instalar como servicio de usuario de systemd (no se requiere sudo, utiliza rutas XDG).

Solo en Windows

• --service-account <DOMAIN\user>: ejecuta el servicio de Windows bajo una cuenta específica. El valor predeterminado es LocalSystem.
• --service-account-password <password>: contraseña para --service-account.

reinicio del relé

Detenga y reinicie el servicio de cliente de Relay. Detecta binarios actualizados y aplica cambios en la definición del servicio. Los siguientes marcadores pueden anularse en el momento del reinicio (todos están predeterminados sin cambios, a menos que se indique lo contrario):

• --config / --config-file: reemplaza la configuración del cliente.
• --accept-license-agreement: acepta el acuerdo de licencia durante el reinicio, útil al actualizar un servicio instalado más antiguo que no persistía en la aceptación de la licencia.
• --log-level: cambiar el nivel de registro.
• --logs-dir <path>: reubica el directorio de registro del servicio instalado. Requiere el cliente de Relay 26.4.2 o posterior.
• --log-retention-days <days>: cambiar la retención de registros rotados. Mínimo 7; introduzca -1 para dejarlo sin cambios. Requiere el cliente de Relay 26.4.2 o posterior.
• --heartbeat-interval: cambia el intervalo de latidos. Mínimo 10; introduzca 0 para dejarlo sin cambios.
• --reconnect-interval: cambia el intervalo de reconexión proactiva. Mínimo 1800 (30 minutos) cuando se establece. Pulse 0 para deshabilitar, o -1 para dejarlo sin cambios.
• --enable-onprem-executor: habilita o actualiza la configuración del ejecutor local en un servicio instalado.
• --disable-onprem-executor: elimina la configuración del ejecutor local persistente y reinicia sin el proceso del ejecutor.
• --onprem-executor-listen-port, --onprem-executor-java-home, --onprem-executor-dep-dir: actualiza la configuración específica del ejecutor local. Pasar cualquiera de estos marcadores implica una actualización del ejecutor.

Si el servicio instalado ya tiene habilitado el ejecutor local, relay restart <id> conserva su configuración. Para actualizar Relay y el ejecutor juntos, extrae ambos archivos del nuevo archivo y ejecuta relay restart <id> utilizando el nuevo binario de Relay. Las comprobaciones de Java y del ejecutor se ejecutan antes de que se detenga el servicio.

registros de Relay

Mostrar salida de registro para un cliente de Relay.

• -f, --follow: transmitir nuevas líneas de registro continuamente.
• -n, --lines <N>: número de líneas desde el final. Predeterminado 50.

lista de retransmisión

Mostrar todos los clientes de Relay en esta máquina con el estado, la versión, las marcas de tiempo de creación y actualización y el nombre del grupo cuando esté disponible. Los nombres de grupo largos se truncan en la salida de la tabla.

• --json: emite una salida JSON para la automatización y la creación de scripts, incluidos los nombres completos de los grupos.

Describir el Relay (Cliente de Relay 26.4.2 o posterior)

Muestra información detallada para un cliente de Relay, incluidos el ID y el nombre del grupo, el ID del secreto, el estado, la versión, el modo de servicio y la ruta ejecutable, los latidos configurados y los intervalos de reconexión, el nivel de registro, las rutas locales y las marcas de tiempo.

Una sección Ejecutor local informa si el ejecutor está habilitado y, cuando lo está, el puerto de escucha, la versión del runtime, la ruta del runtime, el inicio de Java y el directorio de dependencias.

• --json: emite salida JSON para automatización y scripting.

recargar el repetidor

Vuelve a obtener la configuración del proxy de Test Cloud y aplícala sin reiniciar. Úsalo como alternativa si un punto final recién añadido devuelve 404.

parada de relé

Detén el servicio de cliente de Relay. La configuración y las credenciales se conservan. El cliente de Relay se puede reiniciar más tarde.

Eliminar retransmisión

Detén el servicio, anula el registro de Test Cloud y elimina toda la configuración y credenciales locales.

• -f, --force: eliminar localmente sin cancelar el registro de Cloud. Utilízalo cuando las credenciales sean ilegibles o los recursos en la nube ya se hayan eliminado.

paquete de soporte de Relay [id]

Recopilar un archivo redactado de configuración, registros y metadatos del sistema para un ticket de soporte de UiPath. Omita [id] para agrupar todos los clientes de Relay en la máquina. Las credenciales y las claves de cifrado nunca se incluyen. Consulta Recopilar un paquete de soporte para obtener todos los detalles.

versión de Relay

Imprima la versión del cliente de Relay, la fecha de compilación y el hash de confirmación de Git.

Seguridad antivirus y de puntos finales

Si su organización ejecuta software de protección de puntos finales, añada exclusiones para el binario de Relay y su directorio de datos para evitar que el cliente de Relay se bloquee o se ponga en cuarentena. Para las configuraciones del cliente de Relay 26.4.2 que se conectan a través de cloud.uipath.com, permita cloud.uipath.com:443. Para las versiones de cliente de Relay anteriores a 26.4.2, configure los proxies de inspección de TLS, los dispositivos DLP y los sistemas IDS/IPS para omitir la inspección de <region>-relay.uipath.com:443.

Si habilitas el ejecutor local, extiende esas exclusiones al ejecutable de Java, el directorio de dependencias y onprem-executor.log. El servicio de Relay inicia un proceso secundario de Java que carga bibliotecas de conectores de terceros, que algunos productos de protección de puntos finales bloquean de forma predeterminada. Ámbito de las exclusiones a esas rutas en lugar de a todo el árbol de directorios.

Destination	Puerto	Protocolo	Acción
cloud.uipath.com	443	Https	Allow
<region>-relay.uipath.com	443	TLS	Permitir + omitir la inspección TLS para versiones de cliente de Relay anteriores a 26.4.2