Présentation
Voici l'essentiel de ce que vous obtenez et à qui cela s'adresse. MTProto Proxy sur VPS achemine le trafic Telegram via le protocole MTProto avec une obfuscation de type TLS, ce qui lui permet de passer inaperçu sur les réseaux restrictifs. Les usages typiques incluent l'hébergement de proxy personnel ou communautaire et le maintien de l'accès à Telegram là où il est filtré. Les profils concernés sont les utilisateurs soucieux de leur vie privée et les administrateurs de communautés Telegram.
Description
Cette image fournit un MTProto Proxy open-source configuré pour des communications privées avec Telegram. Elle est conçue pour les régions ou réseaux soumis à la censure, en utilisant MTProto et en prenant en charge l'obfuscation TLS pour dissimuler le trafic.
Accéder à l'interface web
Le premier démarrage est simple : le serveur transmet directement les informations à Telegram. Il vous suffit d'importer un lien prêt à l'emploi et de vous connecter, sans tableau de bord supplémentaire.
Récupérez le lien tg://proxy depuis /root/.proxy sur le serveur, puis importez-le dans le client Telegram pour commencer à utiliser le proxy.
Fonctionnalités avancées
Ce sont les caractéristiques concrètes qui comptent pour un transport Telegram. Elles garantissent un accès fiable et utilisable dans les environnements filtrés.
- Compatibilité avec le protocole MTProto pour le trafic Telegram.
- Prise en charge de l'obfuscation TLS pour masquer les modèles de trafic.
- Adapté à l'hébergement de proxy personnel ou communautaire et aux réseaux restreints.
Facilité d'utilisation
Choisissez une image LTS compatible, le provisionnement s'exécute au premier démarrage, et le service est géré via l'init natif.
- Options d'OS : Ubuntu 24.04 LTS ou Ubuntu 22.04 LTS.
- Système init : systemd pour le contrôle du service.
- Provisionnement : cloud-init pour la configuration initiale.
Priorité aux performances
Les performances brutes de Cloudzy maintiennent une latence faible et un débit stable pour les sessions Telegram. Les vCPUs EPYC dédiés, la DDR5 RAM et les disques 100 % NVMe réduisent le temps au premier octet. Un backbone 10 Gbps absorbe les pics sans saturer les connexions, tandis que les snapshots à la demande et la facturation horaire vous permettent de tester des modifications en toute sécurité et d'augmenter la capacité uniquement quand le trafic le justifie.
Contrôle total du site
Considérez cela comme votre propre environnement isolé pour le transport.
Vous disposez d'un accès root pour gérer les règles de pare-feu, planifier les sauvegardes et contrôler le rythme des mises à jour. L'isolation KVM maintient vos charges de travail VM à l'écart des voisins bruyants, et une IP dédiée garantit un accès prévisible.
Des outils puissants
Voici ce que vous obtenez directement et ce qui est à portée d'un clic :
- Service MTProto Proxy tournant sous systemd pour un démarrage, un arrêt et un suivi d'état simples.
- Provisionnement cloud-init pour que l'instance soit prête dès le premier démarrage.
- Assistant de démarrage : un fichier tg://proxy enregistré à /root/.proxy pour une importation rapide dans Telegram.
- Outils de la plateforme : snapshots pour des retours arrière sécurisés et facturation horaire pour cloner des nœuds de test éphémères si nécessaire.
Couverture mondiale
Placez le proxy au plus près de vos utilisateurs pour réduire le temps d'aller-retour. Cloudzy dispose de 10 points de présence répartis sur trois continents :
- Amérique du Nord : New York City, Dallas, Miami, Utah, Las Vegas
- Europe : Londres, Amsterdam, Frankfurt, Zurich (Suisse)
- Asie-Pacifique : Singapour
Chaque site offre une liaison montante 10 Gbps, un mix d'opérateurs Tier-1 et un SLA de disponibilité à 99,95 %. La seule variable, c'est la distance.
Détails de l'application
Système d'exploitation :
Ubuntu 24.04 LTS
Ubuntu 22.04 LTS
Runtime :
Non spécifié.
Application :
MTProto Proxy.
Système d'init :
systemd.
Provisionnement :
Cloud-init.
Minimum RAM : 1 GB
Minimum CPU : 1 vCPU
Disque minimum : 10 GB
Déployer MTProto Proxy de Cloudzy sur VPS maintenant: hébergez votre propre proxy compatible Telegram et importez le lien dans votre client en quelques minutes.
Important : configuration et responsabilités liées au domaine
Vous disposez d'un accès SSH/root complet sur chaque OCA. Cela implique aussi que vos modifications peuvent casser l'application. Lisez ceci avant de modifier les configurations.
- Vous gérez le domaine. Nous ne vendons ni n'hébergeons de domaines/DNS. Si l'application nécessite un domaine, vous devez faire pointer votre domaine vers le serveur (A/AAAA/CNAME, et MX/TXT si nécessaire). L'émission de SSL et de nombreux tableaux de bord dépendent de l'exactitude de cette configuration.
- Changer le domaine ou le nom d'hôte après l'installation n'est pas une opération anodine. De nombreuses OCAs intègrent le domaine dans leurs fichiers de configuration (.env, reverse proxy, URLs applicatifs). Si vous le modifiez, mettez également à jour :
- Le reverse proxy (Nginx/Caddy) et les certificats TLS
- Les URLs "externes"/de base et les URLs de callback/webhook de l'application
- Tous les liens codés en dur dans l'application ou ses extensions
- Les identifiants sont importants. Renommer l'administrateur par défaut, changer les mots de passe ou modifier les ports des services sans mettre à jour la configuration de l'application peut vous bloquer l'accès ou interrompre des services. Gardez vos identifiants à jour et cohérents entre l'application, le proxy et les intégrations.
- Modifier les serveurs de noms peut provoquer une interruption de service. Migrer votre domaine vers de nouveaux serveurs de noms ou modifier les enregistrements NS déclenche des délais de propagation. Planifiez vos changements, réduisez le TTL à l'avance et vérifiez les enregistrements A/AAAA avant de basculer.
- Modifier le pare-feu ou les ports peut couper l'accès. Si vous modifiez SSH, HTTP/HTTPS, RDP ou les ports applicatifs, mettez à jour les pare-feux (UFW/CSF/groupes de sécurité) et les règles du reverse proxy en conséquence.
- Les ports SMTP sont restreints par défaut. Les ports de messagerie sortante (par ex., 25/465/587) peuvent être bloqués pour prévenir les abus. Si votre OCA doit envoyer des e-mails, demander l'accès SMTP auprès du support ou utilisez un fournisseur de messagerie transactionnelle (SendGrid/Mailgun/SES) via API ou un SMTP approuvé.
- E-mail et listes d'autorisation. Si l'application envoie des e-mails ou reçoit des webhooks, changer d'IP ou de nom d'hôte peut affecter la délivrabilité ou les listes d'autorisation. Mettez à jour SPF/DKIM/DMARC ainsi que toutes les listes d'IP autorisées.
- Avant tout changement important, prenez un snapshot. Utilisez la fonctionnalité capture instantanée/sauvegarde du panneau en premier. Si un plugin, une mise à jour ou une modification de configuration tourne mal, vous pouvez revenir en arrière en quelques minutes.
- Périmètre du support. Nous fournissons le serveur et l'image OCA préinstallée. La configuration au niveau applicatif (domaines, DNS, paramètres de l'application, plugins, code personnalisé) reste à la charge de l'utilisateur.
Règle simple : si vous touchez le domaine, les ports, les mots de passe, les noms d'hôtes ou les configurations proxy/SSL, pensez aussi à mettre à jour les paramètres de l'application, et faites un snapshot au préalable.
