**Reiniciar servidor HTTP**: detiene y vuelve a iniciar el servicio HTTP del servidor. Es necesario reiniciarlo para que se apliquen los cambios realizados en la configuración de los virtual hosts, sus rutas y sus perfiles de seguridad.
 **Iniciar servidor HTTP**: inicia el servicio HTTP del el servidor. Al arrancar nos informará sobre el host o hosts que se han iniciado. Ejemplo:
> Servidor HTTP iniciado en los siguientes hosts: 8080 ssl, 8081 misitio.com, 8082 ssl
 **Detener servidor HTTP**: detiene el servicio HTTP del servidor y nos informará sobre el estado de la operación.
* Esta acción no detiene la escucha en el puerto de acceso a los módulos Web de vAdmin y vDataClient.
* Esta acción detiene el acceso a las rutas pero sí permite el acceso a los ficheros estáticos.
 **Nuevo virtual host**: permite crear y configurar un nuevo host virtual en el vServer.
 **Eliminar virtual host**: permite borrar un host virtual.
 **Refrescar**: refresca la lista de host virtuales del servidor.
La configuración se guarda en dos archivos del [directorio de configuración del servidor](/38/velneo-vserver/instalacion-y-configuracion/estructura-de-directorios.md#ficheros-de-configuracion), en la carpeta `Velneo\httpserver`:
* `httpserver.vsi`: es un archivo binario, utilizado para una carga más rápida.
* `httpserver.json`: es un archivo de configuración en formato JSON, legible y editable.
El servidor (`vServer`) tiene una lógica específica para garantizar la mejor experiencia de carga y para mantener la coherencia de la configuración.
El servidor intenta cargar la configuración de la forma más eficiente posible, priorizando el archivo binario.
**1. Carga por Defecto (Desde el Binario)**
Este es el escenario de carga habitual, que optimiza el rendimiento.
* Al solicitarse la carga de la configuración, y el archivo binario `httpserver.vsi` existe, la configuración se carga directamente desde el archivo binario.
* Si ocurre algún error durante esta carga, el mensaje correspondiente se mostrará en el panel de mensajes de vAdmin.
**2. Carga de Respaldo (Desde JSON y Regeneración Binaria)**
Este escenario se ejecuta cuando no existe el fichero binario.
* Al solicitarse la carga de la configuración, y el archivo binario `httpserver.vsi` no existe, la configuración se carga desde el archivo JSON (`httpserver.json`).
* Inmediatamente después de la carga exitosa, el servidor genera y guarda una nueva versión del archivo binario (`httpserver.vsi`).
* Si ocurre algún error durante esta carga, el mensaje correspondiente se mostrará en el panel de mensajes de vAdmin.
{% hint style="info" %}
Si necesitamos que `vServer` cargue la configuración desde el archivo JSON de forma intencionada (por ejemplo, tras editarlo manualmente o después de una migración), debemos detener el servidor, borrar el archivo `httpserver.vsi` . Al arrancarlo nuevamente, se generará el vis a partir del JSON.
{% endhint %}
Al realizar un cambio en el panel de administración (`vAdmin`), el servidor se asegura de que la configuración quede guardada en ambos formatos.
{% hint style="info" %}
En servidores locales, por defecto, siempre se abre un puerto 443 en el servidor para servir los componentes (vAdmin Web, vDataClient Web). Pero es configurable.
{% endhint %}
## Las propiedades de un **Virtual host** son las siguientes:
### Configuración general
#### Activo
Nos permite activar o desactivar el *virtual host*.
#### Puerto de escucha
En este parámetro especificaremos el puerto de escucha para este *virtual host*. Ejemplo: 8080
#### Nombre del host
Si vamos a usar un dominio, lo especificaremos aquí. Ejemplo: midominio.com.
Este parámetro es opcional.
#### SSL
En este parámetro configuraremos si el protocolo a usar va a ser con SSL (HTTPS) o sin SSL (HTTP).
#### Fichero certificado
Si la conexión va a ser SSL, aquí podemos especificar la senda en disco del fichero correspondiente al certificado.
{% hint style="info" icon="circle-exclamation" %}
El certificado debe ser ***fullchain***: es el archivo que garantiza la jerarquía de confianza entre el servidor y una autoridad reconocida. Contiene, en un orden específico, la lista de certificados necesarios para que un navegador valide la conexión como segura:
1. Certificado de Entidad Final: El certificado específico de tu dominio (el "suscriptor").
2. Certificados Intermedios: Uno o varios certificados que actúan como puente, demostrando que tu dominio ha sido validado por una Autoridad Certificadora (CA) de confianza.
Si necesitas información sobre cómo componerlo, haz clic [aquí](/38/velneo-vserver/instalacion-y-configuracion/parametros-configurables-de-velneo-vserver/componer-certificado-fullchain.md).
{% endhint %}
Este parámetro es opcional.
#### Fichero clave privada
Si la conexión va a ser SSL, y en el parámetro anterior hemos especificado un certificado, aquí podemos especificar la senda en disco del fichero de la clave privada del certificado.
Este parámetro es opcional.
### Rutas
Una ruta define qué sirve el virtual host en una dirección determinada: una aplicación, una API REST de una instancia, etc.
El botón  nos permitirá configurar una ruta y el botón  eliminarla.
Por cada ruta, debemos cumplimentar los siguientes parámetros:
#### Ruta
Que será la ruta para la web dentro del host que tendrá la instancia que queremos servir.
Siempre debe ir precedida del carácter "/".
Ejemplos:
`/auth` , `/verp-api`
#### Tipo
Qué servirá la ruta. Los valores posibles son:
* **App**: para ejecutar vía Web objetos programados en aplicaciones Velneo como, por ejemplo, [procesos accesibles Web](/38/velneo-vdevelop/proyectos-objetos-y-editores/de-aplicacion-y-datos/proceso.md#accesible-web).
* **Apirest instancia**: API REST nativa de una instancia: acceso a sus datos y ejecución de los procesos y búsquedas que la propia instancia permita por esta vía. Está pensada para integraciones con otros sistemas.
* **Apirest admin**: API REST de administración del propio vServer: usuarios, grupos, soluciones, instancias, tareas, monitorización, licencia y servicio HTTPS. No da acceso a los datos de las instancias. Solo se puede seleccionar si la ruta no tiene instancia asignada.
* **MCP**: servidor MCP del propio vServer, para conectar asistentes y agentes de inteligencia artificial. Si se asocia una instancia, las herramientas de datos trabajarán con ella por defecto.
* **Health**: comprobación del estado del servidor, pensada para monitorización. Sin credencial, devuelve únicamente el estado (`ok` o `degraded`).
* **Metrics**: métricas de funcionamiento del servidor.
{% hint style="info" %}
Todo virtual host nuevo incluye de serie una ruta de tipo **Health** (`/health`), otra de tipo **Metrics** (`/metrics`) y otra de tipo **Apirest admin** (`/api`) con los métodos GET y POST y limitada a las operaciones de arranque. La ruta `/api` se crea sin ningún método de seguridad, por lo que no se sirve hasta que se configure en su perfil de seguridad.
{% endhint %}
#### Usuario
Usuario declarado en el vServer con permisos de acceso a la instancia.
#### Instancia
Que será el identificador que tenga en vAdmin la instancia que queremos servir.
#### IPs permitidas
Permite limitar el acceso a la ruta a determinadas direcciones IP. Tiene dos opciones:
* **Permitir todas las IPs**: no se aplica ninguna restricción.
* **Restringir a IPs específicas**: el botón  abre el editor **IPs permitidas**, donde podemos añadir y eliminar entradas con los botones **Añadir** y **Eliminar**.
Cada entrada del editor tiene una **Dirección IP** y un **Tipo**, que puede ser **IP directa** (la de la conexión), **X-Forwarded-For** (la del cliente real detrás de un proxy inverso) o cualquiera de las dos.
{% hint style="warning" %}
127.0.0.1 no cubre ::1: son direcciones distintas y hay que listar las dos.
{% endhint %}
La restricción de IPs se puede definir en dos niveles:
* **En la ruta**: se aplica a todos los perfiles de seguridad de la ruta.
* **En un perfil de seguridad**: se aplica solo a ese perfil (ver [Seguridad](#perfiles-de-seguridad)).
Lo habitual es utilizar uno de los dos niveles. Si se configuran ambos, se combinan como una condición Y: la petición debe cumplir las dos restricciones para ser aceptada.
#### Reservar licencia por sesión
Si la casilla está activada, que es lo habitual, cada sesión de la ruta reserva una licencia al autenticarse y la libera al terminar. Así se garantiza que haya conexiones disponibles para la ruta: sin reserva, una web podría dejar de responder si se supera el número de usuarios. Si no hay licencias disponibles, la petición recibe un error 503 con la cabecera `Retry-After`. Si la desactivamos, la ruta no consume licencias.
Esta opción no está disponible en las rutas de tipo **Apirest admin**.
#### **Métodos HTTP permitidos**
Solo en rutas de tipo **Apirest admin**. Las casillas **GET**, **POST**, **PUT** y **DELETE** indican los métodos que admitirá la ruta. Las peticiones con un método no marcado responden con un error 405. HEAD se permite si se permite GET, y PATCH se trata como PUT.
En la misma fila se encuentra la casilla **Solo operaciones de arranque**, que se describe a continuación.
#### **Solo operaciones de arranque**
Solo en rutas de tipo **Apirest admin**. Si está marcada, la ruta solo atiende el inicio y cierre de sesión y la consulta y activación de la licencia; el resto de peticiones responden como si la ruta no existiera (error 404). Esta comprobación se hace antes que la de los métodos permitidos: con la casilla marcada, una petición PUT o DELETE a una operación que no sea de arranque responde 404, no 405.
La casilla viene marcada de serie en la ruta `/api`, para poder gestionar un servidor recién instalado mediante peticiones. Para usar el resto de la API hay que desmarcarla.
#### Perfiles de seguridad
Cada ruta puede tener uno o varios perfiles de seguridad. Se muestran en una rejilla con las columnas **Nombre**, **Habilitado**, **Autenticación**, **IPs permitidas** y **Permisos**. Un texto bajo la rejilla indica el método de seguridad activo.
Los botones de la derecha actúan sobre el perfil seleccionado:
* **Añadir**: crea un perfil nuevo.
* **Modificar**: abre la ventana de edición del perfil. También se abre haciendo doble clic sobre el perfil.
* **Copiar**: duplica el perfil.
* **Eliminar**: borra el perfil. No está disponible cuando solo hay un perfil.
* **Importar permisos…**: importa los permisos dados en otro perfil configurado en ese servidor.
**Propiedades de un perfil de seguridad**
Cuando creamos o editamos un perfil de seguridad, en la parte superior de la ventana se indican el **Nombre** del perfil, la casilla **Habilitado** y el botón **Eliminar perfil**. El resto se organiza en tres pestañas. **Aceptar** y **Cancelar** son propios de esta ventana, de modo que podemos descartar los cambios de un perfil sin descartar los de la ruta.
**Autenticación**
El **Método de autenticación** puede ser:
* **API Keys estáticas**: permite definir hasta dos claves. Por cada una indicamos una **Etiqueta** y, opcionalmente, una fecha de caducidad (**Caduca**, con formato AAAA-MM-DD; si se deja vacío, no caduca). El botón **Generar/Regenerar** crea la clave y **Eliminar** la borra. Los iconos junto a la clave permiten copiarla y mostrarla.
* **OAuth externo (IdP ajeno)**: delega la autenticación en un proveedor de identidad externo. El **Modo** indica cómo se valida el token:
* **Introspección (RFC 7662)**: el servidor consulta al proveedor para comprobar cada token. Los parámetros son:
* **URI de introspección**: dirección del servicio de introspección del proveedor.
* **Client ID ante el IdP**: la credencial de este servidor ante el proveedor.
* **Client Secret ante el IdP**: el secreto ante el proveedor.
* **Caché de introspección**: segundos durante los que se conserva el resultado de la introspección (60 por defecto).
* **JWKS (firma verificada en local)**: el servidor verifica localmente la firma del token, sin consultar al proveedor en cada petición. El parámetro propio de este modo es la **URI de JWKS**, la dirección donde el proveedor publica sus claves públicas (por ejemplo, `https://idp.ejemplo.com/.well-known/jwks.json`).
Además, en ambos modos se pueden indicar:
* **Scopes exigidos**: si se deja vacío, no se exige ningún scope.
* **Issuer esperado (iss)**: si se deja vacío, no se valida el claim `iss`.
* **Audience esperada (aud)**: si se deja vacío, no se valida el claim `aud`.
El Client Secret se guarda en claro. Solo se usa en el modo Introspección.