Varias cuentas de redes sociales con aislamiento del navegador
Cómo mantener cada cuenta de redes sociales gestionada de forma legítima con su propia identidad de navegador, proxy y sesión persistente, y qué no puede controlar el aislamiento.
Quieres la documentación estructurada de Identidad?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Cómo pueden las plataformas vincular una cuenta con otra
Llevar varias cuentas de redes sociales es una necesidad habitual para agencias, marcas con páginas regionales, community managers y creadores que separan su presencia personal de la profesional. La dificultad es que las plataformas buscan relaciones entre cuentas y solo pueden juzgar por las señales que expone una sesión. Cuando dos cuentas comparten demasiadas de esas señales, la plataforma puede considerarlas relacionadas, y el resultado puede ser menos alcance, funciones limitadas o una suspensión, aunque cada cuenta cumpla un propósito distinto y legítimo.
La primera señal es la huella del navegador. Una página puede leer el resultado de Canvas, el nombre del renderizador WebGL, el comportamiento del audio, las fuentes instaladas, el tamaño de pantalla y muchas otras propiedades del navegador. Si dos cuentas informan los mismos valores en todo, es una señal fuerte de que detrás hay un mismo dispositivo o una misma instalación del navegador. Las plataformas no publican qué combinaciones valoran, así que lo prudente es suponer que cada valor compartido suma al vínculo.
La segunda señal es la red. Las cuentas que inician sesión desde la misma dirección IP, sobre todo en un intervalo corto, se asocian con facilidad. Rotar la dirección de salida no resuelve el problema: si una misma dirección aparece aunque sea una vez en el historial de dos cuentas, el vínculo puede existir, porque la plataforma guarda su propio registro de desde dónde ha entrado cada cuenta. Las direcciones constantes y propias de cada cuenta son más fáciles de explicar que las que cambian en cada visita.
La tercera señal es el estado almacenado. Las cookies, localStorage y datos similares atan un navegador a la sesión de una cuenta. Si dos cuentas llegan a ejecutarse en el mismo perfil o contexto del navegador, la plataforma puede ver los mismos identificadores almacenados en ambas. Es el vínculo más directo y también el más sencillo de evitar, porque el almacenamiento se puede separar por completo.
La cuarta señal es el comportamiento, y ningún ajuste del navegador puede corregirla. Las cuentas que siguen a las mismas personas, publican en el mismo minuto, reutilizan el mismo texto o inician sesión una tras otra desde el mismo escritorio producen un patrón que nada tiene que ver con las huellas. Lo mismo ocurre con los identificadores de dispositivo que una aplicación o una plataforma guarda tras el primer inicio de sesión, y con los datos de verificación, como teléfonos y correos de recuperación, que dos cuentas tengan en común.
Cuando una plataforma decide que unas cuentas están relacionadas, las consecuencias varían. El contenido puede mostrarse a menos gente, funciones como la frecuencia de publicación o los mensajes pueden limitarse, a una cuenta se le puede pedir una verificación adicional y, en los casos más graves, todas las cuentas vinculadas pueden suspenderse a la vez. Como las reglas no son públicas y cambian con el tiempo, un equipo debe planificar como si cualquier señal compartida pudiera importar y leer las condiciones de cada plataforma sobre tener más de una cuenta antes de empezar.
Por qué las configuraciones habituales siguen dejando cuentas vinculables
Los perfiles de navegador separados son lo primero que prueba la mayoría de los equipos. Sí dividen las cookies y localStorage, lo que elimina el vínculo directo de almacenamiento. No cambian lo que el navegador informa sobre la máquina, porque cada perfil sale de la misma instalación en el mismo hardware. Los valores de Canvas, WebGL, audio y fuentes siguen siendo idénticos en todos los perfiles, así que el vínculo por huella permanece.
Las ventanas privadas ofrecen una sesión limpia, sin cookies ni historial anteriores, pero informan la misma huella que la ventana normal. Además lo olvidan todo al cerrarse, de modo que cada sesión nueva exige iniciar sesión otra vez. Los inicios de sesión repetidos desde una sesión nueva son justo el tipo de evento que activa verificaciones adicionales, lo que hace de las ventanas privadas una mala opción para cuentas que deben seguir con la sesión abierta y mostrarse coherentes durante meses.
Las extensiones que reescriben valores de la huella desde dentro de la página solo cambian lo que los scripts de la página pueden leer por esas vías. La cobertura depende de la extensión, los valores pueden contradecir lo que el navegador informa por otras vías, y la página puede ver que un script los tocó. Una huella cambiada a medias que se contradice a sí misma suele ser más difícil de explicar que una sin cambios. Los equipos que usen este enfoque deberían comprobar qué cambia realmente en lugar de fiarse de una lista de funciones.
Las máquinas virtuales separan el sistema operativo, la descripción del hardware y la pila de red, lo que es un aislamiento sólido. También son pesadas. Cada cuenta necesita una imagen de disco, memoria y actualizaciones, y mantener coherentes muchas imágenes supone una carga operativa real. Para unas pocas cuentas de larga duración, una máquina virtual es razonable. Para una agencia con muchas cuentas de clientes resulta difícil de mantener.
Los navegadores comerciales para varias cuentas varían mucho. Unos cambian los valores de la huella mediante scripts de página, otros los cambian más a fondo en el navegador, y otros ofrecen sobre todo un gestor de ventanas cómodo alrededor de perfiles corrientes. Antes de adoptar cualquiera, plantea tres preguntas concretas: qué valores de la huella difieren por cuenta, cómo se enlaza el proxy a cada cuenta y dónde vive el almacenamiento de cada una. Las respuestas importan más que el nombre del producto.
Construir una identidad de navegador para cada cuenta
El principio es sencillo: cada cuenta recibe su propio conjunto de ajustes y ninguna parte de ese conjunto se comparte. Contiene un perfil de navegador, una ruta de proxy, una zona horaria, una configuración regional y una lista de idiomas, una semilla de ruido y un lugar donde guardar el almacenamiento. Anota el conjunto en un registro de cuentas cuando crees la cuenta y trátalo desde entonces como parte de ella. Cambiarlo más tarde modifica lo que ve la plataforma, por eso debe ser una decisión deliberada y no un efecto secundario de una actualización de herramientas.
Un registro útil indica, para cada cuenta, la plataforma, el responsable, el nombre del archivo de perfil, la semilla de ruido, la etiqueta de la ruta de proxy, la ubicación del directorio de datos o del estado de almacenamiento guardado, la zona horaria y la configuración regional, y la fecha de la última comprobación. Guarda los secretos, como las contraseñas del proxy, en un gestor de secretos y deja en el registro solo una referencia. Cuando un compañero se hace cargo de una cuenta, el registro muestra qué hay que conservar, de modo que el traspaso nunca se convierta en motivo para reconstruir el conjunto desde cero.
Hay dos formas de aplicar el conjunto con BotBrowser. La primera es una instancia dedicada: cada cuenta tiene su propio arranque del navegador con su propio archivo de perfil, proxy, zona horaria, configuración regional, semilla de ruido y directorio de datos de usuario. Es la separación más fuerte y la más fácil de razonar, ya que no se comparte nada salvo la máquina. El coste son los recursos: cada instancia lleva su propia carga de navegador, por lo que este esquema encaja mejor con un conjunto moderado de cuentas de larga duración que con una flota muy grande.
La segunda forma es un conjunto de parámetros por contexto. Se arranca una instancia del navegador con un perfil base y cada cuenta recibe su propio contexto de navegador. BotBrowser documenta que cada contexto puede llevar su propio perfil, User-Agent, zona horaria, configuración regional, semilla de ruido, proxy y la mayoría de los parámetros de BotBrowser, y que las páginas de un contexto no pueden ver ni cambiar la huella de otro. Los parámetros se aplican mediante el comando BotBrowser.setBrowserContextFlags en una sesión de nivel de navegador, y deben aplicarse antes de que se abra la primera página de ese contexto. La documentación indica una licencia ENT Tier3 como requisito de este modo. Los contextos de Playwright también mantienen separadas las cookies y localStorage por diseño, de modo que la separación del almacenamiento llega junto con la de la huella.
Elige el perfil para que coincida con el contexto operativo real de la cuenta. Una cuenta que representa a una empresa en Alemania encaja con un perfil y una ruta de salida que tengan sentido en Alemania, y una página regional de una marca en el Reino Unido encaja con una configuración británica. Usa perfiles que coincidan con tu versión principal de BotBrowser y mantén el mismo perfil para la misma cuenta durante toda su vida. Un perfil nuevo a mitad del historial de una cuenta cambia la identidad de navegador que la plataforma ya ha registrado, y la plataforma puede interpretarlo como un dispositivo nuevo.
La semilla de ruido es la parte que más fácilmente se olvida. Es un número entero que hace reproducible la salida de Canvas, WebGL y audio: la misma semilla produce la misma salida tras un reinicio y una semilla distinta produce una salida distinta. Da a cada cuenta su propia semilla, guárdala en el registro junto al perfil y no la reutilices nunca en otra cuenta de la misma plataforma. Usar un mismo perfil para dos cuentas con semillas distintas es posible, pero los perfiles separados aportan más variedad y son la mejor opción por defecto.
Proxy, configuración regional y almacenamiento de sesión de cada cuenta
El proxy es donde se produce la separación de red. Da a cada cuenta una dirección dedicada cuando el proveedor pueda ofrecerla y evita compartir direcciones entre cuentas de la misma plataforma. Una sesión fija, que mantiene la misma dirección durante mucho tiempo, suele parecerse más a un usuario normal que una salida que cambia cada pocos minutos. Elige la ubicación que corresponda al mercado de la cuenta. Que la dirección sea residencial o de un centro de datos, y lo limpio que sea su historial, depende del proveedor del proxy y no del navegador.
La zona horaria, la configuración regional y el idioma deben coincidir con la ubicación de salida. BotBrowser los deriva del proxy cuando se dejan en automático, así que el proxy tiene que configurarse a través del propio BotBrowser. La documentación aconseja fijar el proxy en los parámetros de BotBrowser y no con la opción de proxy de la biblioteca de automatización, porque solo así los valores geográficos siguen a la salida. Cuando un valor deba diferir de la salida, por ejemplo un responsable que está en un país y gestiona una página de otro, fíjalo de forma explícita y anota el motivo.
El almacenamiento de sesión mantiene la cuenta con la sesión abierta. Con una instancia dedicada, da a cada cuenta su propio directorio de datos de usuario y guarda ese directorio junto a la cuenta. Con el modo por contexto, guarda el estado de almacenamiento de cada contexto al terminar la sesión y vuelve a cargarlo en el siguiente arranque, algo que Playwright admite directamente. Las sesiones guardadas se comportan como credenciales: consérvalas en un almacenamiento protegido, no copies nunca una en el directorio de otra cuenta y elimínala cuando la cuenta se retire. Una sesión estable también reduce los inicios de sesión repetidos y los avisos de verificación que invitan.
Los cambios de personal y la baja de cuentas requieren el mismo cuidado. Cuando un responsable se va, traspasa la sesión y las credenciales de la cuenta por el proceso de acceso habitual del equipo en lugar de enviar una carpeta del navegador por correo. Cuando se cierra una cuenta, elimina su directorio de datos, su estado de almacenamiento guardado y su asignación de proxy, y libera la semilla y la dirección para que nada de la cuenta antigua se asocie por error a una nueva.
La autenticación en dos pasos pertenece a la cuenta, no al navegador. Cada cuenta debe tener su propio número de teléfono o su propia entrada en una aplicación de autenticación, y los códigos de respaldo deben guardarse con la persona responsable de esa cuenta. BotBrowser no genera códigos, no recibe mensajes ni completa verificaciones, así que el equipo tiene que diseñar ese proceso por separado y mantenerlo al día cuando cambie el personal.
El ritmo de actividad y las condiciones de la plataforma son responsabilidad del operador. Planifica las publicaciones y la interacción a partir de un calendario acorde con el propósito real de cada cuenta, y no uses el aislamiento para coordinar actividad entre cuentas que una plataforma no permitiría. Algunas plataformas permiten varias cuentas para uso empresarial y otras lo restringen, así que revisa las condiciones de cada una. El aislamiento reduce la probabilidad de que las señales técnicas conecten cuentas, pero no hace aceptable el comportamiento coordinado.
Comprobar que las cuentas siguen separadas
Antes de poner una cuenta en marcha, haz una comprobación breve desde el propio navegador de esa cuenta, con páginas que controles o páginas de prueba públicas. Empieza por la dirección. Abre un servicio que devuelva la IP, como httpbin.org/ip, y confirma que la dirección es la ruta dedicada de la cuenta y que difiere de la de todas las demás. Si aparece la conexión de tu oficina o de tu casa, el proxy no se aplicó y la cuenta no debe usarse todavía.
Después compara la zona horaria y el idioma que informa el navegador con la región de la cuenta. Una salida de Nueva York que informa la zona horaria de Berlín, o al revés, apunta a un error de configuración. Corrígelo antes de usar la cuenta para nada, porque una discrepancia es una señal que las plataformas pueden leer, y es fácil de evitar cuando se detecta durante la preparación.
A continuación compara Canvas y WebGL. En una página de prueba que controles, dibuja una forma fija y lee el nombre del renderizador gráfico en el navegador de cada cuenta. Las cuentas con perfiles distintos deberían mostrar valores de renderizador distintos, y las cuentas que comparten perfil pero usan semillas de ruido distintas deberían mostrar una salida de Canvas diferente. Si dos cuentas se ven idénticas, comprueba que cada una recibió su propio conjunto y que los parámetros del contexto se aplicaron antes de abrir la primera página.
Por último, comprueba el almacenamiento. Inicia sesión en un sitio de prueba desechable con una cuenta, abre el mismo sitio con otra y confirma que no se traslada ninguna cookie ni estado guardado. Lleva un minuto y detecta el error más dañino, que es que dos cuentas compartan por accidente un directorio de datos o un contexto.
Repite una versión más corta de la misma comprobación cuando una cuenta empiece a comportarse de otro modo, por ejemplo cuando los inicios de sesión desencadenen verificaciones con más frecuencia o una página se cargue en un idioma inesperado. Un cambio en el conjunto de direcciones del proveedor del proxy, un directorio de datos caducado o una actualización que reinició un ajuste son causas habituales, y el registro te dice con qué conjunto comparar.
Anota cada resultado en el registro de cuentas con la fecha, la versión del navegador, el nombre del perfil, la semilla de ruido y la etiqueta de la ruta de proxy. Repite la comprobación tras cualquier cambio en el navegador, el perfil o el proveedor del proxy. Una comprobación superada demuestra que la configuración es la que pretendías. No demuestra cómo tratará la plataforma las cuentas, porque sus propias señales y reglas quedan fuera de lo que puedes observar.
Qué cubre BotBrowser y dónde termina
BotBrowser puede asignar a cada cuenta su propio perfil, proxy, zona horaria, configuración regional y semilla de ruido, ya sea como instancia dedicada o como un conjunto de parámetros por contexto definido mediante BotBrowser.setBrowserContextFlags, de modo que cada cuenta conserve una identidad de navegador distinta y estable durante la sesión, con almacenamiento separado. Eso ayuda a un equipo a evitar que las señales de huella, almacenamiento y red vinculen cuentas. BotBrowser no garantiza que una plataforma no vincule ni restrinja cuentas, y no puede controlar los patrones de comportamiento, las IP de proxy compartidas o de baja calidad, la verificación de cuentas, la 2FA ni las condiciones de la plataforma.
Cuando crece el número de cuentas, las limitaciones principales son la memoria y el tiempo de procesador. Mantén un registro que indique, para cada cuenta, su perfil, semilla, etiqueta de ruta de proxy, directorio de datos y plataforma, arranca las cuentas en grupos pequeños en lugar de todas a la vez y cierra las sesiones que estén inactivas. Pasar algunas cuentas a una segunda máquina es una forma normal de mantener ágil cada navegador, y el registro hace que ese traslado sea seguro porque cada conjunto ya está escrito.
Para profundizar, consulta aislamiento de navegador para varias cuentas para el modelo de aislamiento, proxy por contexto para la asignación de rutas, reproducibilidad de la semilla de ruido para el manejo de semillas y zona horaria, configuración regional e idioma para los ajustes regionales.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.