Lo esencial sobre FTP en pocos minutos
- FTP sirve para transferir archivos entre un programa cliente y un servidor.
- Usa un canal de control y otro de datos, algo que explica muchos fallos con firewalls.
- En entornos empresariales sigue siendo útil para hosting, migraciones y automatizaciones heredadas.
- FTP sin cifrado no es adecuado para redes públicas ni para archivos sensibles.
- Si puedes elegir, normalmente merece más la pena FTPS o SFTP.
Qué es FTP y qué problema resuelve
FTP, o File Transfer Protocol, es un estándar de red creado para compartir archivos entre equipos distintos de forma ordenada. Yo lo explico siempre así: no está pensado para editar documentos en la nube ni para sincronizar carpetas como haría una suite colaborativa, sino para transportar ficheros entre dos puntos bien definidos.
Su lógica es sencilla. Un cliente se conecta a un servidor, se autentica si hace falta y después puede subir, bajar, listar o reorganizar archivos dentro de las carpetas permitidas. Eso lo hace muy útil en tareas muy concretas: publicar contenidos en un hosting, mover backups, intercambiar lotes de documentos con un proveedor o automatizar cargas nocturnas desde un sistema interno.
La clave está en entender su alcance. FTP resuelve bien el transporte, pero no aporta por sí solo colaboración, historial de cambios, comentarios, control documental avanzado ni sincronización inteligente. Por eso sigue vivo en entornos técnicos, aunque no sustituye a una plataforma de trabajo compartido. Con esa idea clara, ya tiene más sentido mirar cómo viajan realmente los datos.

Cómo funciona una conexión FTP por dentro
Una sesión FTP no se comporta como una descarga simple de navegador. De hecho, usa dos canales distintos: uno de control y otro de datos. El canal de control gestiona el inicio de sesión y los comandos, mientras que el de datos transporta los archivos o listados de directorio. Esa separación es la razón de muchas de sus virtudes, pero también de gran parte de sus problemas con redes corporativas y routers domésticos.
En la práctica, lo normal es que el control pase por el puerto 21. El canal de datos puede abrirse de formas distintas según el modo de trabajo. Aquí es donde aparecen los dos escenarios clásicos:
| Modo | Quién abre el canal de datos | Qué suele pasar en la vida real |
|---|---|---|
| Activo | El servidor se conecta al cliente | Funciona peor detrás de firewalls o NAT porque el tráfico entrante puede quedar bloqueado. |
| Pasivo | El cliente se conecta a un puerto que anuncia el servidor | Suele encajar mejor en redes modernas porque evita muchas barreras de entrada. |
Si alguna vez un FTP “parece conectado” pero no termina de listar carpetas o transferir archivos, el problema muchas veces está ahí: el canal de control funciona, pero el de datos no logra abrirse bien. Yo suelo recomendar modo pasivo cuando hay firewalls intermedios o equipos fuera de la misma red local. Esa arquitectura explica muchos fallos y también aclara cuándo FTP encaja de verdad en un flujo de trabajo.
Dónde encaja en nube y archivos
FTP sigue teniendo sitio cuando el objetivo es intercambio técnico de archivos, no colaboración editorial. En una empresa pequeña o mediana, esto suele verse en cinco escenarios muy concretos: subir archivos a un alojamiento web, mover copias de seguridad entre servidores, entregar paquetes de documentos a un proveedor, sincronizar sistemas heredados o lanzar procesos automáticos desde un ERP o una aplicación interna.
En cambio, no me parece la mejor herramienta para carpetas compartidas entre departamentos, porque ahí manda otra lógica. Si necesitas edición simultánea, control de versiones, permisos por documento y acceso fácil desde cualquier dispositivo, una solución de almacenamiento en la nube suele ser más adecuada. FTP es bueno para transportar; la nube colaborativa es mejor para trabajar sobre el archivo una y otra vez.
| Situación | ¿FTP encaja? | Por qué |
|---|---|---|
| Publicar archivos en un hosting | Sí | Permite subir y reemplazar ficheros de forma directa. |
| Cargas automáticas de copias de seguridad | Sí | Funciona bien en tareas repetitivas y programadas. |
| Compartir documentos entre varios equipos | No demasiado | Faltan colaboración, historial y gestión documental real. |
| Integraciones con software antiguo | A veces | Es útil cuando el sistema solo entiende este protocolo. |
La conclusión práctica es clara: úsalo como herramienta de intercambio, no como entorno de trabajo compartido. Y cuando entras en ese terreno, la seguridad deja de ser un detalle técnico para convertirse en la decisión principal.
Seguridad y límites que no conviene minimizar
El punto débil más conocido de FTP es que, por sí solo, no cifra ni las credenciales ni el contenido transferido. Eso significa que, en una red no controlada, alguien con capacidad de interceptar tráfico podría leer usuarios, contraseñas y archivos. Para un entorno empresarial, eso es demasiado riesgo si los datos tienen cualquier valor operativo o legal.
Por eso conviene diferenciar entre tres opciones que a menudo se confunden:
| Protocolo | Protección | Cómo lo veo yo |
|---|---|---|
| FTP | Sin cifrado nativo | Solo lo usaría en entornos muy controlados o por compatibilidad. |
| FTPS | FTP con TLS | Buena opción si quieres mantener la lógica de FTP pero añadir cifrado. |
| SFTP | Transferencia sobre SSH y cifrado integrado | Suele ser la opción más limpia para nuevos proyectos. |
La diferencia importante es que SFTP no es FTP aunque el nombre confunda. Funciona de otra manera y suele simplificar la seguridad y el paso por firewalls. FTPS, en cambio, conserva la estructura de FTP y le añade una capa de cifrado, lo que puede venir bien cuando ya existe infraestructura FTP y no quieres rehacer todo el flujo. Si tienes que decidir hoy, mi regla es simple: FTP solo por compatibilidad; FTPS o SFTP para trabajo real con datos sensibles.
Cómo elegir bien el protocolo y evitar errores típicos
Cuando una empresa empieza a usar FTP de forma operativa, los fallos más caros no suelen venir del protocolo en sí, sino de una mala configuración. Yo me fijaría primero en estos puntos, porque ahorran tiempo y llamadas al soporte:
| Error habitual | Qué pasa | Qué haría yo |
|---|---|---|
| Usar FTP plano en redes públicas | Las credenciales y los archivos quedan expuestos | Pasar a FTPS o SFTP en cuanto sea posible. |
| Olvidar el modo pasivo | La conexión parece abrir, pero la transferencia falla | Activar pasivo si hay firewalls, routers o NAT en medio. |
| Subir binarios en modo texto | Los ficheros pueden corromperse | Usar modo binario para imágenes, ZIP, PDF o instaladores. |
| Compartir una sola cuenta entre varias personas | Se pierde trazabilidad y control | Crear usuarios individuales con permisos limitados. |
| Dejar acceso a carpetas demasiado amplias | Aumenta el riesgo de borrados o subidas erróneas | Restringir cada cuenta al directorio que necesita. |
También conviene pensar en el objetivo del flujo. Si lo que buscas es mover archivos una vez al día entre dos sistemas internos, FTP o FTPS pueden ser suficientes. Si el uso es más frecuente, hay usuarios remotos o circulan documentos sensibles, yo elevaría el nivel y elegiría SFTP o una plataforma de nube con control documental. Esa decisión marca más diferencia que cualquier ajuste menor.
Lo que me parece más útil hoy para una pyme que mueve archivos
Si tuviera que resumir la decisión en una sola idea, diría esto: FTP sigue siendo útil como protocolo de transferencia, pero ya no debería ser la opción por defecto. Para una pyme, lo sensato es usarlo solo cuando el sistema lo exige o cuando la compatibilidad pesa más que otra cosa. En cuanto tengas margen de elección, prioriza SFTP o FTPS y reserva la nube colaborativa para el trabajo diario con documentos.
Mi recomendación práctica es empezar por tres preguntas: qué tipo de archivo vas a mover, quién necesita acceder y qué nivel de seguridad exige el proceso. Si la respuesta incluye colaboración entre personas, versiones o permisos documentales, la nube gana. Si lo que necesitas es un intercambio técnico entre sistemas, FTP puede seguir sirviendo, pero mejor con cuidado, con modo pasivo bien configurado y con una capa de cifrado si el entorno no es totalmente controlado.
