Diagnóstico previo de conexión
Un diagnóstico previo de conexión es una comprobación por etapas que ejercita una conexión de datos de mercado paso a paso —pasarela, nombre de sistema, inicio de sesión, suscripción y primer tick— e informa de lo que midió cada etapa. Distingue una ruta rechazada de unas credenciales rechazadas y de un flujo aceptado que simplemente está callado.
Senzoukria · Glosario · Actualizado en septiembre de 2026
Las etapas
| Etapa | Pregunta | Qué demuestra al pasar |
|---|---|---|
| Pasarela accesible | ¿Respondió la URL de la pasarela? | Existe la ruta de red; ningún cortafuegos, VPN o proxy la bloqueó |
| Sistema reconocido | ¿Esta pasarela sirve el sistema indicado? | El nombre de sistema está en la lista activa de la pasarela |
| Pasarela y sistema concuerdan | ¿Es correcta la ruta? | Un rechazo posterior no es un error de enrutamiento |
| Autenticación | ¿Aceptó el bróker el inicio de sesión? | Credenciales y habilitación para ese sistema |
| Suscripción de datos | ¿Se aceptó la suscripción al símbolo? | Permiso de datos de mercado para ese símbolo |
| Primer tick recibido | ¿Llegó un tick dentro de la espera? | Los datos fluyen ahora; un mercado tranquilo puede fallar esta etapa |
Por qué una comprobación por etapas supera a un único error
Rechazos idénticos en pantalla han tenido causas distintas: una pasarela equivocada, un nombre de sistema que se movió, una contraseña caducada, una habilitación de datos ausente, un contrato vencido que sigue aceptando suscripciones. Un diagnóstico que se detiene en la primera etapa fallida y nombra lo que midió convierte un vago «login fallido» en un hecho sobre el que el soporte o el proveedor pueden actuar. La guía de Rithmic enumera los puntos a confirmar por separado del lado de la cuenta: nombre de sistema, aplicaciones de terceros autorizadas, disponibilidad de profundidad e histórico, límites de sesión y permisos de enrutamiento.
En Senzoukria
La pantalla de conexiones tiene un «Diagnóstico de conexión» con un botón para ejecutarlo, otro para repetirlo y «Copiar el resultado». Cada etapa informa de «superada», «fallida» o «No ejecutada» con el motivo; por ejemplo, «No ejecutada, no hay contraseña guardada en esta conexión». Su nota declara el método: informa de lo que midió y enumera las causas posibles por frecuencia; nunca designa ninguna como segura.
Cuando todas las etapas pasan pero no llega ningún tick, el diagnóstico muestra «Todo fue aceptado, no llegan datos» y enumera las causas empezando por la más frecuente: el mercado está cerrado para este contrato, el símbolo ya no es el contrato del mes en curso, y otras. La copia del resultado está pensada para pegarse en una solicitud de soporte junto con el intervalo solicitado.
Errores frecuentes
- Cambiar indicadores o reinstalar la aplicación antes de ejecutar el diagnóstico.
- Leer una suscripción superada como prueba de cobertura histórica; el histórico es una habilitación aparte.
- Ejecutar la comprobación un fin de semana y concluir que la cuenta está rota porque no llegó ningún tick.
- Enviar al soporte solo el veredicto final en lugar del resultado copiado etapa por etapa.
Relacionado
- Estado del flujo de datos
- Guardado de credenciales en el llavero
- Software footprint para Rithmic
- Puente de flujo de órdenes con Quantower
Esta página en otros idiomas
Preguntas frecuentes
- El diagnóstico superó todas las etapas pero el gráfico está vacío. ¿Por qué?
- Una suscripción aceptada demuestra permiso, no actividad. El contrato puede estar fuera de su sesión, o el símbolo puede ser un vencimiento caducado que sigue aceptando suscripciones y no negocia nada. Comprueba primero el horario de la sesión y el contrato del mes en curso; el diagnóstico enumera esas causas por orden de frecuencia sin afirmar ninguna.
- ¿El diagnóstico previo se aplica a una conexión por puente?
- Las etapas de pasarela, sistema e inicio de sesión son para conexiones directas. Un puente con NinjaTrader o Quantower se comprueba de otro modo: el indicador del puente debe estar corriendo en un gráfico, el puerto local debe estar libre y el histórico que anunció el puente debe coincidir con el recibido. La guía de Quantower da el comando de PowerShell que confirma el listener.