Badge IP

IP Badge est une “API d’images” légère : elle prend l’IP du visiteur (ou une IP que vous spécifiez) ainsi que country_code (code pays) et country_name (nom du pays, optionnel), les rend sous forme d’une image badge SVG directement intégrable, et la renvoie avec Content-Type: image/svg+xml. Contrairement aux API classiques qui renvoient du JSON, un badge SVG s’affiche comme une image ordinaire dans un README, un tableau de bord, un mur de supervision, une page de statut ou partout où un <img> est supporté, sans traitement front-end supplémentaire.

L’outil utilise une mise en page à deux segments (type shields.io) : à gauche, l’IP ; à droite, le résultat (code pays ou “code + nom du pays”). Les couleurs et les langues se contrôlent via des segments de route. Côté données, la géolocalisation IP s’appuie sur la table locale ip2location_db11 (correspondance de plages IPv4 pour obtenir country_code), et les noms de pays multilingues proviennent de sys_lang_multi, via un mapping par vc_code vers des champs comme name_en / name_zh / name_ja ... (le nom du pays n’est renvoyé que si la route contient un segment de langue). L’outil tente aussi d’extraire la véritable IP client via des en-têtes proxy courants (ex. Cloudflare, X-Forwarded-For), ce qui le rend adapté aux déploiements derrière un CDN, un reverse proxy ou un load balancer.

Le principe clé d’IP Badge est : utiliser la route comme une URL d’image. En ouvrant la route dans le navigateur, vous verrez le badge SVG ; en l’utilisant dans du Markdown ou du HTML, elle s’affichera comme une image. Pour répondre à différents besoins de “densité d’information”, les routes se divisent en deux grandes catégories : myip et check : myip est orienté affichage (IP seule), check est orienté requête (avec informations pays). De plus, le nom du pays n’apparaît que si la route contient -<lang> ; sans langue, seul le code pays est affiché pour garder un badge plus court et “type statut”.

GET /myip

GET /check-ip

GET /check-8.8.8.8

GET /check-ip-zh

GET /check-8.8.8.8-zh

IP Badge permet d’ajouter -<color> à la fin de la route pour contrôler la couleur de fond (souvent la zone résultat à droite), comme sur shields.io : vous pouvez utiliser des tokens simples (blue/green/red/gray) ou une valeur hex à 6 caractères (sans #). Vous pouvez ainsi associer couleur et signification métier, par exemple “green = normal, yellow = à surveiller, red = risque élevé”, afin que le badge transmette à la fois information et sémantique de statut.

Comme IP Badge renvoie une image SVG, l’usage le plus recommandé est l’intégration directe. Dans un README/Wiki GitHub ou GitLab, la syntaxe d’image Markdown suffit ; dans une page web ou un back-office, utilisez simplement la balise <img>. Le principal avantage : pas besoin de logique front-end supplémentaire, ni de gérer du JSON CORS, des templates ou la mise en page des polices — le navigateur sait afficher un SVG comme une image.

![IP Badge](https://s.ipin.io/check-ip-zh-blue)

<img src="https://s.ipin.io/check-8.8.8.8-zh-green" alt="IP Badge" />

IP Badge est très adapté aux besoins “orientés affichage”. Par exemple, sur une page de statut Ops, vous pouvez transformer l’IP/les infos pays de sortie de différents nœuds en un “mur de badges” et voir d’un coup d’œil si un nœud sort depuis une région inattendue ; en opérations de sécurité, vous pouvez intégrer des IP d’alerte sous forme de badges rouges dans des tickets ou notifications (ex. “US United States” / “RU Russia”), permettant aux équipes d’astreinte de comprendre rapidement le contexte de risque sans ouvrir les détails ; lors du debug de chaînes CDN/reverse proxy, accéder à /myip et /check-ip aide à vérifier si l’IP réelle est correctement transmise ou écrasée ; dans des back-offices multilingues ou des SaaS internationaux, l’utilisation de -zh/-en/-ja permet d’afficher différents noms de pays selon la langue, réduisant le coût de maintenance des dictionnaires i18n côté front. Enfin, vous pouvez associer couleurs et statut métier (vert = “autorisé”, jaune = “vérification requise”, rouge = “bloqué/risque élevé”) afin que le badge porte à la fois “info + statut”.

Conseil : si vous exposez le service sur Internet, il est recommandé de mettre en place une politique “en-têtes proxy de confiance” au niveau du reverse proxy ou de l’application, afin d’éviter que des clients falsifient des en-têtes comme X-Forwarded-For et provoquent un affichage incorrect. Il est aussi recommandé d’ajouter des index sur ip2location_db11.ip_from et sys_lang_multi.vc_code, et d’utiliser des en-têtes de cache pour améliorer les performances et la stabilité.