Tutoriales de VPS
Cómo redactar un ticket de soporte de VPS (2026): plantillas de comunicación de alta calidad para reembolsos, migraciones, cambio de IP y resolución de problemas
Muchos problemas de VPS tardan en resolverse no porque sean demasiado complejos, sino porque el ticket en sí está redactado de forma demasiado vaga: sin datos de la instancia, sin marcas de tiempo, sin registros y sin una solicitud clara. Basándose en la documentación de soporte pública de los principales proveedores cloud, este artículo desglosa la redacción de alta calidad para cuatro escenarios frecuentes —reembolsos, migraciones, cambio de IP y resolución de problemas— para ayudarte a reducir las preguntas de ida y vuelta y lograr una gestión más rápida.
Cómo redactar un ticket de soporte de VPS (2026): plantillas de comunicación de alta calidad para reembolsos, migraciones, cambio de IP y resolución de problemas
Cuando muchas personas abren un ticket de soporte de VPS, la primera frase que escriben suele ser:
- Su máquina tiene un problema
- Mi VPS va muy lento
- Quiero un reembolso
- Arréglenlo ya
El problema es que este tipo de ticket no le dice realmente al equipo de soporte: qué máquina, cuándo ocurrió el problema, qué has comprobado ya y cómo quieres que lo gestionen.
El resultado suele ser uno de dos:
- Dos o tres rondas de preguntas de ida y vuelta, con muy poca eficiencia
- Una respuesta con plantilla por su parte que sientes como una evasiva
Pero desde la perspectiva del equipo de soporte, muchos tickets se atascan no porque no quieran gestionarlos en absoluto, sino porque la información que proporcionas no es suficiente para que puedan hacerse cargo directamente.
Y esto no es una suposición mía. En la documentación pública, aunque distintos proveedores cloud redactan de forma diferente sus requisitos de solicitud de soporte, la idea central es muy coherente:
- La API de tickets de Vultr requiere al menos
subjectydescription - Los comandos de tickets de Linode/Akamai Cloud permiten adjuntar directamente IDs de recursos como
linode-idyvolume_id - Scaleway exige explícitamente que proporciones el producto, el recurso afectado, la información del entorno, los registros y los archivos adjuntos
- AWS Support llama directamente a la sección de descripción "la información más importante que proporcionas al equipo de soporte"
Este artículo lo explica a fondo: cómo redactar un ticket de soporte de VPS que tenga más probabilidades de ser gestionado con rapidez, especialmente en los cuatro escenarios de alta frecuencia: reembolsos, migraciones, cambio de IP y resolución de problemas.
Muchos tickets son ineficientes no porque el problema sea necesariamente difícil, sino porque la forma de redactarlos hace imposible hacerse cargo de ellos.
Los cuatro errores más comunes.
Por ejemplo:
- El VPS va lento
- La ruta está rota
- No puedo entrar por SSH
- La IP está bloqueada
Todo esto son solo conclusiones, no pistas sobre las que el equipo de soporte pueda actuar directamente.
Lo que realmente necesitan es:
- Qué instancia
- Desde cuándo
- Cuáles son los síntomas concretos
- Qué comprobaciones has hecho ya
- Qué acción quieres que tomen
"Su servicio es una basura", "llevo mucho tiempo aguantando esto", "si no lo arreglan pido un reembolso": estas frases expresan descontento, pero no ayudan a localizar el problema.
El equipo de soporte no atiende primero tus emociones, sino tu contexto.
Por ejemplo, en el mismo ticket dices a la vez:
- El VPS va lento
- Quiero cambiar la IP
- Además la factura está mal
- Y de paso, ¿puedo migrar al centro de datos de Tokio?
Esto aumenta directamente el coste de la comunicación de ida y vuelta. El equipo de soporte normalmente tiene que separar los problemas primero en lugar de gestionarlos directamente.
Muchos usuarios solo describen el fenómeno sin decir qué quieren realmente:
- ¿Quieres un reembolso?
- ¿Quieres cambiar la IP?
- ¿Quieres migrar el nodo?
- ¿O quieres que sigan solucionando el problema por ti?
Lo que más teme un ticket no es un problema complejo, sino un objetivo poco claro.
Antes de pulsar realmente "Enviar", organiza lo siguiente.
- Número de pedido, ID de instancia, nombre de host, número de servicio
- El periodo exacto en que ocurrió el problema (preferiblemente con zona horaria)
- Síntomas concretos, no sensaciones vagas
- Acciones de diagnóstico que ya has realizado
- Capturas de pantalla, mensajes de error, registros y salidas de comandos relevantes
- Qué quieres que haga el equipo de soporte
- ¿Qué máquina tiene el problema?
- ¿Cuándo empezó el problema?
- ¿Cuáles son los síntomas concretos?
- ¿Qué diagnóstico has hecho ya?
- ¿Qué quieres que haga la otra parte a continuación?
"Esta tarde empezó a ir mal" es demasiado vago.
Una forma mejor de escribirlo es:
- Empezó el 2026-04-17 a las 14:20 UTC+8
- Duró aproximadamente 30 minutos
- Durante ese tiempo hubo 3 tiempos de espera de SSH
Cuanto más clara sea la marca de tiempo, más fácil les resultará consultar los registros de la plataforma, los eventos del nodo, los registros de migración o las fluctuaciones de red.
Si ya has:
- Reiniciado la instancia
- Revisado el grupo de seguridad
- Ejecutado
ping,mtr,traceroute - Revisado
journalctl,dmesgy el registro de errores de Nginx
Entonces escríbelo claramente. Así evitas que el equipo de soporte te vuelva a preguntar por estas acciones básicas en la primera ronda.
Lo que más teme el personal de soporte no es un problema complejo, sino que solo digas "hay un problema" sin dar ninguna pista verificable.
| Elemento de comparación | Ticket de baja calidad | Ticket de alta calidad |
|---|---|---|
| Descripción del problema | "Mi VPS no funciona" | Indica claramente si es un fallo de SSH, pérdida de paquetes, degradación del rendimiento o un problema de facturación |
| Información de contexto | Sin número de pedido ni ID de instancia | Con número de servicio, nombre de instancia y marca de tiempo |
| Pruebas | Sin capturas, sin registros, sin salida de comandos | Adjunta mensajes de error, capturas y fragmentos de registros |
| Diagnóstico realizado | No se indica | Indica claramente que se reinició, se revisó el cortafuegos y se probó la red |
| Objetivo solicitado | "Arréglenlo rápido" | Solicita claramente reembolso, cambio de IP, migración o continuar el diagnóstico |
| Resultado | Preguntas de ida y vuelta | Más probabilidades de entrar en gestión sustantiva de una vez |
Muchas veces, el equipo de soporte no se niega a responder, sino que está esperando que redactes el ticket a un nivel "gestionable".
Las siguientes 4 categorías son los escenarios que los usuarios de VPS encuentran con más frecuencia y que más fácilmente redactan de forma desordenada.
Para facilitar su reutilización directa, las he redactado con el formato "escenario + plantilla + notas".
- Justo después de una compra nueva, descubres que el servicio difiere gravemente de lo esperado
- La descripción pública no coincide claramente con la configuración real
- La máquina tiene problemas críticos persistentes y varias rondas de gestión no han producido mejoras sustanciales
- Ya has confirmado que no se trata simplemente de una configuración insuficiente o de un error de operación por tu parte
Subject: Refund request for order [订单号 / 服务编号]
Hello,
I would like to request a refund for the VPS service associated with order [订单号] / instance [实例 ID].
Purchase time:
[购买时间，带时区]
Issue summary:
[用 1-2 句话说明核心问题，例如：实例创建后持续无法稳定 SSH 登录 / 实际网络表现与公开说明严重不符 / 机器频繁异常重启]
What I have checked:
- [已做动作 1]
- [已做动作 2]
- [已做动作 3]
Evidence:
- [报错截图 / 日志 / 测试结果]
Requested resolution:
I would like to request a refund or let me know whether this case is eligible under your billing/refund policy.
Thank you.
- No escribas solo "quiero un reembolso"; indica siempre el motivo con claridad
- No inventes políticas de la plataforma; deja que ellos decidan según la política real de facturación/reembolso
- Si ya has comunicado con soporte durante 1-2 rondas, adjuntar el número de ticket anterior es aún mejor
2) Plantilla de solicitud de migración (cambio de centro de datos / cambio de host / cambio de nodo)
- El nodo actual lleva mucho tiempo inestable
- La red de un centro de datos concreto es persistentemente anómala
- Se sospecha contención de recursos en la capa del host, con múltiples pruebas que lo respaldan
- El negocio debe conservar el servicio existente pero quiere trasladarse a una ubicación más estable
Subject: Migration request for instance [实例 ID]
Hello,
I would like to request a migration for my VPS instance [实例 ID / 主机名].
Reason for the request:
[例如：当前节点在过去 48 小时内出现多次异常；网络质量持续波动；性能抖动严重]
Observed timeframe:
[开始时间 + 持续时间 + 时区]
Observed symptoms:
- [症状 1]
- [症状 2]
- [症状 3]
Troubleshooting already performed:
- [已做检查 1]
- [已做检查 2]
- [已做检查 3]
Requested resolution:
Please let me know whether this instance can be migrated to another host / node / location, and what downtime or IP changes I should expect.
Attachments / evidence:
- [日志 / 截图 / 测试结果]
- "Migración" no es una frase vacía; debes explicar el motivo y las pruebas de la migración
- Si no puedes aceptar un cambio de IP, indícalo de antemano
- Si tu negocio es sensible al tiempo de inactividad, indica también de antemano si te preocupa más la ventana de inactividad o la estabilidad
- La IP está bloqueada, tiene mala reputación o está muy contaminada
- Un negocio concreto se ve claramente afectado por el estado de la IP
- La IP actual ya no es apta para seguir usándose, pero la instancia en sí no tiene grandes problemas
Subject: IP change request for instance [实例 ID]
Hello,
I would like to request an IP change for my VPS instance [实例 ID / 主机名].
Reason:
[例如：current IP appears blocked / reputation issue / cannot be used for the intended service]
Observed issue:
- [具体表现 1]
- [具体表现 2]
- [具体表现 3]
When the issue started:
[时间点]
Checks already completed:
- [已确认不是本地网络问题]
- [已测试不同网络环境]
- [已检查服务本身配置]
Requested resolution:
Please let me know whether an IP replacement is possible, whether additional charges apply, and whether reverse DNS or network settings will be affected.
Evidence:
- [截图 / 返回信息 / 测试结果]
- No escribas solo "cámbiame la IP"; explica por qué
- No equipares directamente "mal rendimiento del negocio" con "hay que cambiar la IP"
- Si te preocupan el rDNS, los cargos adicionales, el tiempo de inactividad o el impacto en IPv6, pregúntalo todo de una vez
- Ya has hecho un diagnóstico básico pero sigues sin poder determinar si es un problema local, de configuración o de la plataforma
- El problema persiste y hay pruebas reproducibles
- Quieres que la plataforma ayude a comprobarlo más a fondo desde el host, la capa de red o el plano de control
Subject: Troubleshooting request for instance [实例 ID]
Hello,
I need help troubleshooting an issue affecting my VPS instance [实例 ID / 主机名].
Issue summary:
[例如：SSH connections timeout intermittently / network latency increased significantly / disk I/O performance dropped]
Observed timeframe:
[开始时间 + 时区]
Expected behavior:
[原本应该怎样]
Actual behavior:
[现在具体怎样]
Troubleshooting already performed:
- Restarted the instance / service
- Checked firewall or security group settings
- Reviewed relevant logs
- Ran tests such as ping / mtr / traceroute / fio / top / journalctl
Key evidence:
- [贴出最关键的 2-5 行日志或测试结论]
Requested resolution:
Please help review whether there were host-level, network-level, or maintenance-related issues affecting this instance, and advise the next recommended action.
- Lo mejor es escribir "esperado frente a real"
- No pegues todos los registros de golpe; prioriza los fragmentos más críticos
- Si es un problema de SSH, indica claramente si es timeout, connection refused o fallo de autenticación
- Si es un problema de rendimiento, intenta explicar qué capa (CPU, disco o red) es más evidentemente anómala
Las siguientes formas de escribir no están totalmente prohibidas, pero fácilmente dejan al equipo de soporte sin más opción que preguntarte primero.
Por ejemplo:
- Su servicio no sirve
- Demasiado lento, arréglenlo rápido
- Ya está afectando a mi negocio
Estas frases expresan descontento pero no constituyen información ejecutable.
Por ejemplo, preguntar en el mismo ticket a la vez:
- ¿Puedo obtener un reembolso?
- ¿Puedo cambiar la IP?
- ¿Por qué no puedo entrar por SSH?
- ¿Por qué la factura es más alta de lo esperado?
Un mejor enfoque es: un ticket resuelve solo un problema principal.
Por ejemplo:
- Ustedes investíguenlo
- En fin, simplemente no funciona bien
- Deberían poder verlo
Claro que la plataforma puede ver parte de la información, pero no puede ver tus síntomas locales completos, tus expectativas de negocio ni qué acciones has realizado ya.
Por ejemplo, dices "quiero migrar", pero no dices:
- Si puedes aceptar un cambio de IP
- Si puedes aceptar un breve tiempo de inactividad
- Si te importa más la estabilidad o la región
Así que igualmente tendrán que volver a preguntarte.
Lo que más incomoda a muchas personas no es "un problema complejo", sino "no poder ver si la otra parte está avanzando realmente".
Puedes juzgarlo según los siguientes aspectos.
- Te piden que complementes información concreta, en lugar de repetir de forma vaga
- Te dicen claramente qué van a comprobar a continuación
- Explican el alcance posible implicado, como nodo, host, red, facturación o política
- Explican limitaciones, procesos o ventanas de tiempo
- Varias rondas seguidas con respuestas de plantilla casi idénticas
- Ninguna respuesta a los registros, capturas o resultados de pruebas que proporcionaste
- Nunca abordan tu solicitud central, solo te piden que reenvíes información
- Ninguna explicación de la siguiente acción ni ruta de escalado
Pero atención:
"Pedir más información" en sí mismo no equivale a una evasiva.
Si tu primer ticket es realmente vago, es normal que pregunten. Lo que realmente debería preocuparte es que ya hayas completado la información y aun así solo copien plantillas mecánicamente sin entrar en una gestión sustantiva.
Antes de enviar un ticket de soporte de VPS, repasa estos 7 puntos:
- Confirma primero el único objetivo de este ticket: reembolso, migración, cambio de IP o diagnóstico
- Escribe claramente el número de pedido, ID de instancia, nombre de host o número de servicio
- Indica el momento en que apareció el problema, preferiblemente con zona horaria
- Describe síntomas concretos; no escribas solo "muy lento" o "no funciona"
- Adjunta las acciones de diagnóstico que ya has realizado
- Adjunta las capturas, registros o resultados de pruebas más críticos
- Dile claramente a la otra parte el resultado que deseas
Si solo recuerdas una frase, que sea esta:
Un ticket de alta calidad no es "más educado", sino "más completo, más verificable y más fácil de ejecutar para la otra parte".
Esta es también la razón por la que la documentación de soporte pública de distintas plataformas, aunque con redacciones diferentes, acaba desembocando en la misma lógica:
- Necesita un asunto claro y una descripción detallada (Vultr)
- Necesita IDs de recursos (Linode)
- Necesita recursos afectados, información del entorno, registros y archivos adjuntos (Scaleway)
- Necesita una descripción completa, clasificación, archivos adjuntos y, cuando sea necesario, un nivel de gravedad adecuado (AWS)
Cuando proporcionas toda esta información de una vez, muchos tickets en realidad no necesitan tres rondas de ida y vuelta para entrar en la fase de gestión real.