Preguntas frecuentes

Preguntas frecuentes

Guías cortas y prácticas para la configuración, el acceso y las acciones comunes de los clientes.

> ¿Cómo funciona el sistema de crédito de Cli>_?

Un saldo prepago compartido financia todos los servicios aptos y solo se consume mientras están activos.
faq/prepaid-credit-how-it-works

Tu cuenta Cli>_ tiene un único saldo de crédito prepago compartido. Los clientes nuevos aptos solo pueden solicitar Starter Credit después de completar la verificación obligatoria de la cuenta y contra abusos. Los servicios aptos activos consumen el saldo con el tiempo. La estimación mensual usa 31 días y un servicio nuevo solo puede arrancar si el saldo cubre al menos 7 días. El aviso rojo aparece cuando la autonomía estimada baja de 7 días; de lo contrario, el aviso naranja aparece cuando baja de 14 días.

Cuando se agota el saldo, el servicio se suspende después de 7 días, deja de consumir crédito y comienza el plazo de retención y eliminación de 7 días. Antes de la fecha mostrada puedes reiniciarlo con crédito suficiente. Cancelar un servicio provisionado también lo suspende e inicia el mismo plazo. Un servicio pendiente y no provisionado puede desactivarse inmediatamente. Después del plazo comienzan la desactivación y la retirada del servicio provisionado. Force delete desactiva el servicio de inmediato, omite la retención e inicia su retirada del runtime activo; la finalización depende del procesamiento del despliegue y GitOps. Las copias de seguridad y Offsite Archive tienen políticas de retención independientes.

Ejemplo ilustrativo de OpenCode a 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR al día. Tras 10 días completos se han consumido unos 3,19 EUR. Si el saldo inicial era exactamente 9,90 EUR y no había otros servicios, quedan unos 6,71 EUR. El consumo posterior se detiene al desactivar el servicio.

El ejemplo es orientativo. Siempre prevalecen los precios actuales mostrados en Cli>_.

> ¿Cómo generar una clave SSH pública mediante la línea de comandos

Cree una clave SSH pública para acceder de forma segura a su servidor virtual privado (VPS). Comparta solo la clave pública con Cli>_; mantenga la clave privada en su dispositivo.
faq/como-generar-una-clave-ssh-publica

La clave pública se comparte, la clave privada permanece contigo

Solo incluya la clave SSH pública en el proceso de compra o configuración del servicio. La clave privada permanece en su ordenador y no se envía al soporte ni se introduce en un formulario web.

Pasos

  1. Abre una terminal en tu ordenador.
  2. Ejecuta el comando: ssh-keygen -t ed25519 -C "tu_correo@example.com".
  3. Confirma la ubicación del archivo o elige una ruta personalizada. No compartas nunca tu clave privada.
  4. Muestre la clave pública con el comando: cat ~/.ssh/id_ed25519.pub.
  5. Copie toda la línea que comienza con ssh-ed25519 y péguela en el campo de clave pública SSH durante el proceso de compra o configuración del servicio.
  6. Copie la línea completa que empieza con ssh-ed25519 y péguela en el campo "Clave pública SSH".

PowerShell de Windows 10/11

  1. Abra PowerShell o Windows Terminal.
  2. Ejecute el comando: ssh-keygen -t ed25519 -C "tu_correo@example.com".
  3. Presione Enter para guardar la clave en C:\Users\tu_usuario\.ssh\id_ed25519, o ingrese una ruta personalizada.
  4. Si Windows solicita una frase de contraseña, utilice una que pueda almacenar de forma segura, o presione Enter para omitirla durante la configuración básica.
  5. Para mostrar la clave pública, utilice el comando: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Copie solo la línea completa que comienza con ssh-ed25519. No copie ni cargue el archivo de la clave privada.
> ¿Cómo crear una clave SSH de forma gráfica en Windows

Guía visual en Windows para crear un par de claves SSH sin usar la línea de comandos.
faq/crear-clave-ssh-windows-interfaz-grafica

Utilice una herramienta de Windows e inserte únicamente la clave pública

Puede crear un par de claves SSH visualmente con un cliente SSH de Windows como PuTTYgen. Cli>_ solo necesita la clave pública. Mantenga el archivo de clave privada en su computadora y no lo cargue a través de un formulario web.

Pasos

  1. Instala PuTTY o abre PuTTYgen si ya está instalado.
  2. Selecciona EdDSA/Ed25519 si está disponible, o RSA 4096 si la herramienta Ed25519 no lo ofrece.
  3. Haz clic en Generar y mueve el ratón sobre el área vacía hasta que se cree la clave.
  4. Agregue una frase de contraseña si desea protección local adicional para la clave privada.
  5. Guarde la clave privada en su dispositivo y manténgala confidencial.
  6. Copie el texto de la clave pública y péguelo en el campo de clave pública SSH en Cli>_.

No comparta información confidencial

No envíe archivos .ppk, claves privadas, contraseñas ni tokens al servicio de atención al cliente ni a través de formularios.

> Importa tu propio dominio

Aprende cómo redirigir tu propio dominio o subdominio a un servicio de CLIopen antes de activar la función "Importar tu propio dominio".
faq/conectar-tu-propio-dominio

¿Qué hace esta configuración?

Usar tu propio dominio permite que el servicio responda a tu propio nombre de host, por ejemplo, app.example.com, en lugar de usar solo el nombre de host generado *.co.cliopen.cloud. Tu DNS debe apuntar a CLIopen antes de que se pueda utilizar de forma segura el nombre de host en el servicio.

Antes de empezar

  1. Elige el nombre de host exacto que deseas utilizar, por ejemplo, app.example.com. La opción más sencilla es usar un subdominio.
  2. Abre la administración DNS en el registrador de dominios o en el proveedor de DNS.
  3. Elimina cualquier registro A, AAAA, CNAME, ALIAS o redirección conflictivo para ese nombre de host.
  4. Mantén activo el nombre de host de CLIopen generado automáticamente hasta que tu propio nombre de host se haya verificado y esté completamente funcional.

Configuración de DNS recomendada para un subdominio

Crea registros DNS para el nombre de host exacto que ingresarás en CLIopen. Para app.example.com, la etiqueta DNS es app. Apúntalo a las direcciones de entrada de CLIopen que te proporcionará el soporte de CLIopen o en la documentación del servicio. Si tu proveedor solicita un tipo de registro, utiliza un registro A para IPv4 y un registro AAAA para IPv6 cuando se proporcionan esas direcciones.

Ejemplo:

app.example.com.  A     <Dirección IPv4 de CLIopen>
app.example.com.  AAAA  <Dirección IPv6 de CLIopen, si está disponible>

Cuando CLIopen proporciona un objetivo CNAME

Algunos servicios pueden proporcionar un nombre de host generado, por ejemplo: service.customer.co.cliopen.cloud. Si las instrucciones de tu servicio especifican explícitamente el uso de un registro CNAME, crea un registro como app.example.com CNAME service.customer.co.cliopen.cloud. Utiliza registros CNAME solo para subdominios, no para dominios raíz (apex), a menos que tu proveedor de DNS admita la función ALIAS o ANAME flattening.

Uso del dominio raíz

Para un dominio sin subdominio como example.com, la mayoría de los proveedores de DNS no permiten un registro CNAME estándar. Utilice registros A/AAAA que apunten a las direcciones de entrada de CLIopen, o utilice la función ALIAS/ANAME de su proveedor si CLIopen le proporcionó un nombre de host de destino.

Delegación de una subzona completa

Si desea que CLIopen gestione los registros en una subzona como apps.example.com, cree registros NS para esa subzona que apunten a los servidores de nombres de CLIopen que recibió. No cambie los servidores de nombres del dominio completo, a menos que desee intencionalmente que CLIopen (u otro servicio DNS) gestione todos los registros.

Lista de verificación

  1. Espere a que se complete la propagación del DNS. Los cambios menores suelen ser visibles en unos minutos, pero algunos proveedores almacenan en caché durante más tiempo.
  2. Verifique que el nombre de host apunte al destino de CLIopen y no al proveedor anterior.
  3. En el campo "Bring your own domain", introduzca el nombre de host exacto, sin `https://` ni ruta.
  4. Después de la actualización, pruebe `https://app.example.com` en su navegador.
  5. Mantenga los registros DNS antiguos solo si no entran en conflicto con el nuevo nombre de host.
> ¿Cómo transferir una zona DNS a CLIopen

Delega el dominio a ns1.cliopen.com y ns2.cliopen.com para que CLIopen pueda publicar registros para toda la zona.
faq/delegar-una-zona-dns

¿Qué significa la transferencia de zona aquí?

En el contexto del DNS para clientes, la transferencia implica cambiar los servidores de nombres autoritativos en el registro de su dominio. Después de delegar a CLIopen, los registros DNS que se agregan en CLIopen se publican desde nuestros servidores de nombres autoritativos.

Antes de cambiar los servidores de nombres

  1. Copie los registros DNS existentes que aún necesite, como los de su sitio web, correo electrónico, verificaciones, SPF, DKIM, DMARC y registros de servicios.
  2. Agregue la zona en CLIopen DNS. Si la delegación aún no está lista, CLIopen la guarda, pero no la activa para el cliente hasta que se complete la validación.
  3. Si es posible, cree los registros necesarios en CLIopen DNS antes de cambiar los servidores de nombres.
  4. Configure la entrada CAA correctamente, ya que los valores incorrectos pueden impedir la emisión de certificados.

Delegue la zona

  1. Abra la configuración del dominio en su registrador, por ejemplo, example.com.
  2. Busque los servidores de nombres (Nameservers), la delegación DNS o la configuración de DNS autoritativo.
  3. Reemplace los servidores de nombres actuales con ns1.cliopen.com y ns2.cliopen.com.
  4. Guarde el cambio y espere a que se propague en el registro y los resolutores.

Validación

Vuelva a CLIopen DNS y haga clic en "Revisar delegación". Cuando los registros NS públicos muestren ns1.cliopen.com y ns2.cliopen.com, la zona se agregará para sincronización y los registros estarán activos desde CLIopen.

> Registro de cuenta e inicio de sesión

Cree una cuenta para su empresa, complete los datos de facturación y asegúrese de que su equipo tenga acceso a la dirección de correo electrónico asociada.
faq/account-registration-and-login

Una cuenta para gestionar pedidos y servicios

Utilice su cuenta como un lugar permanente para realizar pedidos, administrar datos de facturación, dominios y servicios, y comunicarse con el soporte técnico. Es recomendable utilizar una dirección de correo electrónico profesional a la que el equipo pueda acceder incluso después de cambios en el personal.

Antes de realizar tu primer pedido

  1. Regístrese con su dirección de correo electrónico profesional.
  2. Confirme el mensaje de correo electrónico si se le solicita.
  3. Complete los datos de facturación antes de realizar un pedido pago.
  4. Activa la autenticación de dos factores tan pronto como esté disponible.

Acceso para equipos

No compartas contraseñas con tus colegas a través de chat o correo electrónico. Si varias personas necesitan acceso, utiliza un gestor de contraseñas interno o solicita el procedimiento recomendado para equipos; el soporte técnico no necesita tu contraseña ni tu token de inicio de sesión.

> Estimación mensual, estimación anual y consumo diario real

Los precios mensuales y anuales son solo orientativos. En los servicios de pago anticipado, el consumo diario determina el cargo después de confirmar cualquier cambio.
faq/billing-periods-and-credit-burn

Esta comparación no es un calendario de facturación

Utilice la estimación mensual como referencia para 31 días, y la anual como referencia para 372 días. El consumo real del crédito se realiza en función del tiempo de uso del servicio y de la configuración confirmada, especialmente en servicios prepagados.

Qué debes verificar al cambiar el precio

  1. Compara el consumo diario antes y después del cambio.
  2. Ten en cuenta que un mayor uso de CPU, RAM o disco, o las opciones de pago, pueden aumentar el consumo diario.
  3. El cambio se considerará efectivo solo después de la confirmación, el posible pago y su aplicación.
  4. Para la contabilidad, guarda la confirmación del pedido y el historial de crédito.

Consulte información específica para un período determinado

Al soporte le será más útil si proporcionas el número de pedido, el nombre del servicio y las fechas que deseas verificar. No envíes datos bancarios completos, extractos íntegros ni capturas de pantalla con información personal innecesaria.

> Estado del pedido después del pago

Es posible que, tras la realización del pago, el pedido requiera un tiempo para su confirmación por parte del proveedor. Solo cree una copia del pedido si el primero ha sido cancelado o caducado de forma clara.
faq/order-status-and-payment-confirmation

Pendiente no siempre significa fallo

Después de regresar de la página de pago, el pedido aún podría estar esperando confirmación del proveedor de pagos. Mientras que el estado no sea claramente fallido o expirado, un nuevo pedido duplicado puede complicar innecesariamente la conciliación.

¿Qué hacer después del pago

  1. Después de completar el pago, regresa a Cli>_.
  2. En tu cuenta, verifica el estado del pedido y cualquier mensaje relacionado con el pago.
  3. Si el pedido aún está pendiente, dale tiempo al proveedor para que lo confirme.
  4. Si tiene algún problema, envíe al soporte el número de pedido y la referencia de pago, si es posible.

Qué no enviar

El equipo de soporte no necesita los datos de la tarjeta de pago, la contraseña ni el justificante bancario completo. Solo necesita el número de pedido, la hora del pago, el estado visible y una captura de pantalla enmascarada si aparece un error.

> Datos que aceleran la configuración del servicio

Prepara el nombre del servicio, el dominio, el tamaño del almacenamiento, la dirección de correo electrónico de acceso y la clave SSH pública; no incluyas datos confidenciales en los formularios.
faq/service-setup-information-needed

Valores precisos ahorran tiempo

Utilice los formularios para ingresar valores públicos o no confidenciales: nombre del servicio, dominio, plan DNS, tamaño de almacenamiento, CPU, RAM, correo electrónico de administrador o clave SSH pública. Las contraseñas, las claves privadas y los tokens deben mantenerse fuera del formulario.

Prepárate antes de realizar el pedido

  1. Elige un nombre de servicio reconocible para tu equipo.
  2. Decide si vas a utilizar un dominio propio o un hostname temporal del sistema.
  3. Prepara la clave SSH pública, si el servicio la requiere.
  4. Verifica el tamaño del almacenamiento y los recursos según la aplicación que vayas a ejecutar.

No compartas información confidencial

Si no estás seguro de si un dato es confidencial, pregunta sin enviarlo. No envíes claves privadas, contraseñas, tokens, volcados de bases de datos ni archivos de configuración completos al chat o al pedido.

> Modificar la CPU, RAM, disco o período de almacenamiento después del pedido

Edite el servicio existente a través de sus detalles, no creando un nuevo pedido duplicado; al cambiar los recursos, puede afectar el precio, el costo del servicio, el consumo diario de crédito, el reinicio y el riesgo de interrupción.
faq/change-service-resources-after-order

¿Está actualizando un servicio existente o creando uno nuevo?

Si el servicio ya está en funcionamiento, realice los cambios de recursos desde la sección de detalles del mismo. Una nueva solicitud crearía un servicio adicional en lugar de modificar el existente y podría cambiar el precio, el consumo diario de créditos y el comportamiento operativo después de la confirmación, el pago (si es necesario) y la aplicación de los cambios.

Antes de confirmar el cambio

  1. Consulta el uso actual de CPU, RAM, disco, copias de seguridad y la retención de Offsite Archive.
  2. Verifica el nuevo precio diario y su impacto en tu crédito.
  3. Lee las notificaciones sobre reinicios, mantenimiento o interrupciones.
  4. Antes de realizar un cambio que pueda ser riesgoso, exporte sus propios datos importantes.

Qué hacer si el cambio no se realiza según lo esperado

Envíe el nombre del servicio, la hora del cambio, el estado visible y cualquier mensaje de error. No envíe claves privadas, contraseñas ni tokens; para el diagnóstico es suficiente con el contexto público y una captura de pantalla enmascarada.

> Cancelación del servicio y plazo de eliminación de datos

El servicio provisionado se suspende primero, se muestra un plazo de retención visible y configurable, y posteriormente puede realizarse la eliminación permanente.
faq/cancel-service-and-data-retention

Cancelar no implica la eliminación inmediata de todos los servicios

Para un servicio ya provisionado, primero se suspende y se muestra un plazo visible configurable antes de su eliminación definitiva, lo que permite restaurarlo o exportar sus datos. Los pedidos pendientes sin pago y sin datos en ejecución pueden comportarse de manera diferente, y la limpieza permanente solo ocurre después de que finaliza el período de vida útil.

Verifique antes de cancelar

  1. Cree su propia exportación de datos que necesite conservar a largo plazo.
  2. Lea la fecha y hora de eliminación programada para un servicio suspendido.
  3. No confunda las copias de seguridad con el archivo externo (Offsite Archive) con la eliminación del ciclo de vida del servicio.
  4. Si tiene alguna duda, contacte con el soporte técnico antes de la fecha de eliminación.

Es posible que no sea posible recuperar los datos después del plazo establecido.

Después de la fecha visible, no debe asumir que los datos siguen disponibles. Para consultas, envíe el número de pedido y el nombre del servicio, no exportaciones de bases de datos ni credenciales.

> Copias de seguridad y solicitudes de restauración

Las copias de seguridad se utilizan para la recuperación operativa, no como un sustituto de las exportaciones; la restauración puede sobrescribir datos más recientes.
faq/backups-and-restore-requests

La copia de seguridad no es un archivo permanente ni una exportación

El período de retención de las copias de seguridad depende del producto y las opciones seleccionadas. Una copia de seguridad ayuda a la recuperación operativa en caso de error, pero no reemplaza una exportación propia, un archivo de auditoría ni un Offsite Archive. La restauración puede sobrescribir cambios más recientes.

Cómo preparar una solicitud de restauración

  1. Indique el nombre del servicio y el número de pedido.
  2. Describa la fecha y hora aproximadas a las que desea volver.
  3. Especifique si necesita restaurar toda la instancia o solo una parte, si el producto lo permite.
  4. Incluya un error visible o contexto sin contraseñas, tokens ni claves privadas.

Considere el impacto antes de la recuperación

Si el servicio ha recibido nuevos datos, la restauración podría reemplazarlos por un estado anterior. Antes de confirmar la restauración, informe al equipo y exporte lo que no desea perder.

> ¿Para qué sirve Offsite Archive

Offsite Archive guarda copias de archivo remotas, separadas de las copias de seguridad operativas y del ciclo de vida del servicio.
faq/offsite-archive-purpose

Archivo remoto fuera de la operación diaria

Offsite Archive está diseñado para realizar copias de archivo remotas y almacenar datos durante un período más prolongado. No es un disco activo para una aplicación, ni sustituye las exportaciones locales, ni es lo mismo que las copias de seguridad operativas a corto plazo.

¿Cuándo activarlo?

  1. Utilícelo para los datos que desea conservar fuera del funcionamiento normal del servicio.
  2. Seleccione el número de días de retención según sus requisitos de cumplimiento, necesidades comerciales o objetivos de recuperación.
  3. Tenga en cuenta que el costo aumenta con el volumen almacenado y el tiempo de conservación.
  4. Para grandes volúmenes de datos, planifica el archivo junto con tu propio proceso de exportación.

Cómo evaluar el precio

La base son MB-días: la cantidad de datos almacenados y los días que se conservan. La tarifa se muestra al cliente como EUR/GB/mes y el resultado se redondea a céntimos.

> Selección de CPU, RAM y disco para VPS

Seleccione el tamaño del VPS según la aplicación, la base de datos, la caché, los registros y el crecimiento esperado. El uso excesivo de memoria (OOM) o el intercambio constante indican que es posible que necesite más RAM.
faq/vps-cpu-ram-and-disk-sizing

Comienza según la carga real, no por intuición

Un sitio web estático pequeño tiene necesidades diferentes a las de una base de datos, una aplicación Java, búsquedas o contenedores con compilaciones. Al planificar, considera la memoria de la aplicación, el caché, la base de datos, los registros, las subidas y un margen para el crecimiento.

Señales de que el plan es insuficiente

  1. Aumente la RAM cuando ocurran errores de OOM (falta de memoria), finalización de procesos o uso excesivo del archivo de intercambio (swap).
  2. Aumente la CPU si hay una carga computacional sostenida, compresión, compilaciones o procesos muy activos.
  3. Amplíe el espacio en disco antes de que se llene el sistema de archivos, los registros o la base de datos.
  4. Después de cada cambio, verifique si la aplicación realmente ha dejado de alcanzar el límite original.

¿Qué información enviar al hacer una consulta sobre el tamaño del servidor

Es útil proporcionar el nombre del servicio, el tipo de aplicación, cualquier error visible, la hora aproximada y la configuración actual de CPU, RAM y disco. No envíe contraseñas, claves privadas ni archivos de configuración internos.

> ¿Cuándo tiene sentido una IP pública para un VPS?

Una IP pública dedicada es útil para listas de permisos, acceso entrante, una fuente de salida estable o servicios vinculados a una dirección.
faq/vps-public-ip-options

Primero, determine la dirección del tráfico

Una IP pública no es necesaria para todos los servicios. Generalmente, resuelve los requisitos de socios externos, proveedores o firewalls para listas blancas, una fuente de salida estable o acceso entrante a un puerto específico.

Preguntas antes de solicitar una dirección IP

  1. Pregunte al socio si debe permitir el tráfico entrante, saliente o ambos sentidos.
  2. Utilice nombres DNS en lugar de direcciones IP numéricas siempre que sea posible.
  3. Abra solo los puertos que la aplicación realmente necesita.
  4. Envíe la solicitud de lista blanca al soporte técnico antes de modificar el acceso en producción.

¿Qué puertos mantener cerrados?

Tener una dirección IP pública no significa abrir todos los puertos. Diseñe el acceso solo para los servicios necesarios y no envíe contraseñas, claves privadas ni reglas internas con valores confidenciales.

> Acceso SSH compartido a VPS

Sin adquirir una dirección IP pública, el servidor virtual privado (VPS) se conecta a través de un punto final SSH compartido con un puerto alto. Si tiene una dirección IP pública, también tendrá acceso SSH directo en esa dirección.
faq/shared-ssh-access-for-vps

¿Por qué se utiliza un puerto alto en el acceso SSH compartido?

Varios servicios VPS pueden compartir el mismo punto de acceso SSH público, por lo que cada servicio recibe su propio puerto alto. Este puerto es parte del direccionamiento hacia tu servicio; sin él, la conexión no podría entregarse de forma inequívoca al VPS correcto.

Cómo conectarse según el tipo de acceso

  1. Al usar SSH compartido, copie el nombre de usuario, el host y el puerto desde la configuración del servicio.
  2. Conéctese usando el comando ssh -p <puerto> <usuario>@<host-publico>.
  3. Si el servicio tiene una IP pública adquirida, puede haber un punto de acceso SSH adicional directamente a esa IP o a su nombre DNS, según la configuración del servicio.
  4. Utilice la clave privada solo localmente a través de su cliente SSH o agente; al soporte técnico, proporcione únicamente el host público, el puerto, el nombre de usuario y cualquier error visible.

Cuando tienes una IP pública adicional

Una dirección IP pública no reemplaza necesariamente un punto final SSH compartido. Agrega una ruta directa útil para listas blancas, monitoreo o integraciones; si SSH está habilitado en esa ruta, se utiliza la dirección IP o DNS público del servicio en lugar del host compartido con puerto alto.

> Verificación antes de conectar tu propio dominio

Antes de cambiar de dominio, verifica el servidor DNS autorizado, el nombre de host correcto, el tipo de registro (ya sea dominio principal o subdominio) y la ausencia de registros antiguos que puedan causar conflictos.
faq/custom-domain-readiness-checklist

Es importante el nombre de host exacto

Primero, aclara si estás conectando un dominio principal como example.com o un subdominio como app.example.com. Cada opción puede requerir un tipo diferente de registro DNS, diferentes restricciones del proveedor de DNS y verificación con el registrador.

Antes de cambiar la configuración DNS

  1. Verifica dónde se editan los registros DNS autoritativos del dominio.
  2. Elimina o ajusta los registros A/AAAA, CNAME, ALIAS, ANAME o redirecciones conflictivos.
  3. Utiliza el tipo de registro recomendado para el servicio y el nombre de host.
  4. Después de realizar los cambios, espere a que se complete la propagación del DNS y luego verifique el certificado HTTPS final.

Reversión segura

No desactive el servidor de alojamiento anterior hasta que el nuevo nombre de dominio responda correctamente. Si tiene problemas, proporcione el dominio, el destino esperado y el resultado visible de la configuración DNS, pero no las credenciales de acceso al registrador.

> Tipos de registros DNS para servicios

Los registros A/AAAA apuntan a direcciones, CNAME a alias, MX al correo electrónico y TXT se utilizan para verificaciones, SPF, DKIM o DMARC.
faq/dns-record-types-for-services

No combines registros DNS al azar

Cada tipo de registro DNS cumple una función diferente. Los registros A y AAAA apuntan a direcciones IP, CNAME crea un alias para un subdominio, MX dirige el correo electrónico, TXT contiene verificaciones y políticas de correo electrónico, y CAA limita las autoridades certificadoras.

Al copiar registros

  1. Copie el nombre, el tipo y el valor exactamente según las instrucciones del servicio.
  2. No utilice CNAME en un hostname que ya tenga otros registros, si las reglas de DNS lo prohíben.
  3. Coloque DKIM debajo del selector proporcionado por el proveedor y DMARC normalmente debajo de _dmarc.
  4. Configure CAA cuidadosamente, ya que un valor incorrecto puede bloquear la emisión de certificados.

¿Qué hacer cuando el DNS no funciona

Envíe al soporte el nombre de host, el tipo de registro, el valor esperado y el resultado visible públicamente. No envíe contraseñas para la administración de DNS ni capturas de pantalla con tokens de API.

> Propagación DNS y TTL: Sin garantías de tiempo exacto

El valor TTL determina cuánto tiempo los servidores de resolución pueden almacenar una respuesta anterior. Durante el proceso de propagación, es posible que coexistan resultados antiguos y nuevos hasta que se actualicen las cachés.
faq/dns-propagation-and-ttl

La propagación es un proceso de caché, no una espera mágica

Con DNS, no existe una garantía fija de tiempo. Después de cambiar el DNS autoritativo, diferentes resolutores pueden devolver respuestas antiguas y nuevas hasta que expire su caché según el TTL. Por lo tanto, el resultado puede variar entre redes, países o resolutores de DNS.

Al planificar un cambio

  1. Si el proveedor lo permite, reduzca el TTL antes del cambio planificado.
  2. Después de modificar la configuración DNS, evite realizar cambios aleatorios repetidos mientras se vacía la caché.
  3. Realice pruebas desde varios servidores o redes si los resultados difieren.
  4. Anota la hora del cambio, el valor anterior, el nuevo valor y el TTL.

¿Qué información enviar durante el diagnóstico

Indica el nombre de host, el destino esperado, la respuesta antigua visible, la nueva respuesta visible, el TTL y la hora del cambio. No envíes credenciales de acceso a la cuenta DNS ni notas internas del proveedor.

> Planificación del almacenamiento para Workspace Suite

Para calcular la capacidad necesaria, considere los archivos de usuario, las carpetas compartidas, las versiones, la papelera, las miniaturas, la sobrecarga de sincronización y el crecimiento previsto del equipo.
faq/nextcloud-storage-planning

Workspace Suite crece más allá de los archivos visibles

El espacio se consume con los archivos de usuario, las carpetas compartidas, los archivos eliminados, el historial de versiones, las vistas previas, las miniaturas, los clientes de sincronización y las importaciones. Si el almacenamiento está cerca del límite, es posible que las cargas o la sincronización fallen.

Antes de solicitar capacidad

  1. Suma datos actuales de usuarios y carpetas compartidas.
  2. Añade margen para versiones, papelera, vistas previas y sobrecarga de sincronización.
  3. Considera importaciones grandes, nuevos equipos y crecimiento esperado.
  4. Aumenta la capacidad antes de que los usuarios alcancen el límite.

En caso de problemas de sincronización

Envía información sobre el tamaño del servicio, el uso aproximado, la hora del problema y el error visible del cliente. No envíes archivos personales, contraseñas ni exportaciones de datos de usuario, a menos que el soporte técnico lo solicite específicamente a través de un canal seguro.

> Migración de repositorios a Gitea

Planifique la migración de sus repositorios Git, incluyendo LFS, submódulos, permisos, claves de despliegue, webhooks e integración continua/entrega continua (CI/CD).
faq/gitea-repository-migration

La migración es más que un simple 'git clone'

Además del historial del repositorio, es necesario transferir o volver a configurar propietarios, equipos, ramas protegidas, etiquetas protegidas, Git LFS, submódulos, claves de despliegue, webhooks e integraciones de CI/CD.

Verificación previa a la migración

  1. Enumera repositorios, propietarios, grupos de acceso y cuentas de automatización.
  2. Verifica objetos Git LFS, submódulos, protecciones de ramas y protecciones de etiquetas.
  3. Después de la migración, prueba las operaciones de clonación, envío, Git LFS, submódulos y ejecución de CI.
  4. Revocar o reemplazar los tokens antiguos después de la migración, sin compartir sus valores.

Datos confidenciales durante la migración

No envíe tokens, claves privadas, partes privadas de las claves de implementación ni secretos de CI. Es suficiente proporcionar los nombres de los repositorios, el tipo de integración, el error visible y la información sobre lo que funcionaba antes de la migración.

> Dominio de envío para Listmonk

Para las campañas, prepare un dominio o subdominio de remitente, la identidad del remitente, SPF, DKIM, DMARC, el manejo de rebotes y la opción de darse de baja.
faq/listmonk-sender-domain-basics

La entregabilidad comienza en el dominio

Listmonk necesita una identidad de remitente clara y registros DNS verificables. SPF, DKIM y DMARC deben estar configurados correctamente para el dominio o subdominio desde el que deseas enviar campañas.

Antes de la primera campaña

  1. Elige un dominio o subdominio para las campañas y define la identidad del remitente (From).
  2. Añade registros DNS de verificación, SPF, selector DKIM y DMARC.
  3. Realiza pruebas de envío antes de una campaña real y verifica la entrega, el comportamiento en caso de rebote, la dirección Return-Path y los enlaces.
  4. Verifique las opciones de cancelación de suscripción y List-Unsubscribe antes del envío real.

Los detalles confidenciales del correo electrónico no deben incluirse en los tickets.

Al diagnosticar un problema, proporcione el dominio, el tipo de registro, el valor DNS público y el mensaje de error. No envíe contraseñas SMTP, tokens de API, claves DKIM privadas ni exportaciones de listas de destinatarios con datos personales.

> Configuración del entorno de ejecución para Classic Hosting

Classic Hosting puede funcionar en modo automático o manual. La CPU, la RAM, el almacenamiento, la retención de copias de seguridad, la retención de archivos fuera de línea, las subidas, la caché y los registros influyen en el costo y la estabilidad.
faq/classic-hosting-runtime-settings

El modo automático no es la única opción correcta

Auto Runtime ayuda con proyectos reconocidos, pero el modo manual es útil cuando deseas elegir Nginx, Apache, FrankenPHP o un entorno de ejecución específico. Utiliza el selector de PHP solo donde el entorno de ejecución elegido lo admita.

Configuración previa al despliegue

  1. Elige el modo de Runtime automático o manual según el framework y la forma de compilación.
  2. Selecciona PHP 8.2, 8.3 o 8.4 solo para escenarios de PHP compatibles.
  3. Configura la CPU, la RAM, el disco, la retención de copias de seguridad y el archivo Offsite según los datos y el tráfico.
  4. Después de la implementación, prueba las subidas, la caché, los registros y los errores visibles de la aplicación.

Cuando la aplicación no se inicia

Envía el modo de ejecución, el idioma o la versión de PHP, cualquier error visible, los cambios realizados y la hora aproximada del despliegue. No envíes archivos .env, contraseñas, tokens ni registros completos que contengan información sensible.

> ¿Qué información es seguro enviar al soporte?

Es más útil proporcionar números de pedido, nombres de servicios, dominios, horarios, servidores públicos, puertos, tiempos de retención de copias de seguridad, almacenamiento en la nube, subidas, caché, registros, capturas de pantalla y errores visibles, sin incluir información confidencial.
faq/support-safe-information-to-share

Una solicitud de calidad debe contener información relevante, no datos confidenciales.

El equipo de soporte puede responder más rápido cuando recibe el número de pedido, el nombre del servicio, el dominio, el host o puerto público, la hora del problema, los cambios realizados y un mensaje de error visible preciso.

Contenido seguro para el ticket

  1. Indique el número de pedido, el servicio visible, el dominio, la hora aproximada y el host público o puerto relevante cuando corresponda.
  2. Para problemas de hosting, incluya el modo de ejecución, el lenguaje o la versión de PHP, la CPU, la RAM, el almacenamiento, la retención de copias de seguridad, la retención del archivo externo, las subidas, la caché y los registros, e indique qué cambios se realizaron recientemente.
  3. Adjunte capturas de pantalla solo después de ocultar contraseñas, tokens, claves privadas, sesiones y datos personales.
  4. Si no estás seguro de si un dato pertenece al ticket, pregunta primero sin enviarlo.

Lo que nunca debe enviarse

No envíes contraseñas, claves privadas, frases de recuperación, tokens de API, cookies de sesión, exportaciones de bases de datos, archivos .env completos, registros con información confidencial ni detalles internos de la infraestructura.