Configuration proxy de SearXNG : sortie de l'instance, résultats locaux et largeur d'écran

D'où proviennent la catégorie cartes et les résultats d'entreprises ?

Dans cette architecture, les résultats locaux proviennent d'une catégorie distincte. La liste web générale est alimentée par une source, les résultats cartographiques et de lieux par une autre ; les deux ne relèvent pas de la même logique de classement. Si vous ne voyez pas de fiche d'entreprise, le premier point à vérifier n'est pas votre réglage proxy mais si la catégorie cartes est activée.

L'origine de l'information de localisation est un autre sujet. Les sources cartographiques s'appuient le plus souvent sur le nom de lieu contenu dans la requête : lorsque vous écrivez un nom de ville ou de quartier, les résultats se concentrent sur cette zone. Le pays de l'adresse de sortie n'a pas nécessairement un rôle déterminant ici ; ajouter un nom de lieu à la requête est un signal bien plus fort que l'indice côté réseau.

L'autorisation de localisation du navigateur est une troisième entrée et fonctionne indépendamment du proxy. Si vous accordez cette autorisation, le navigateur peut partager votre position réelle ; cela vous amène à voir un ensemble de résultats locaux inattendu alors que vous utilisez une sortie pays. Garder l'autorisation de localisation désactivée dans le profil de mesure élimine d'emblée deux signaux contradictoires.

• Vérifiez au début de chaque série que la catégorie cartes est activée.
• Écrivez le nom de lieu dans la requête ; ne vous fiez pas à l'indice réseau.
• Désactivez l'autorisation de localisation du navigateur dans le profil de mesure.
• Ajoutez à la ligne de journal la source dont provient une fiche d'entreprise.
• Suivez les résultats locaux comme une série distincte de la liste web générale.

Si vous comparez la surface locale de différents pays, consultez la liste des localisations pour les options de pays et, pour les sorties fixes côté européen, proxy Allemagne vous pouvez consulter cette page.

Pourquoi mesurer séparément écran étroit et écran large ?

L'interface de cette couche utilise une mise en page responsive : le même ensemble de résultats est dessiné selon des dispositions différentes suivant la largeur de la fenêtre. Sur un écran large, certains blocs passent dans la colonne latérale ; sur un écran étroit, ces mêmes blocs descendent dans le flux principal ou entrent dans une section repliée. Même si l'ordre des résultats n'a pas changé, la disposition que vous voyez à l'écran, elle, a changé.

Il est donc insuffisant de noter simplement « en troisième position » dans votre carnet de mesure. Tant que vous n'indiquez pas à quelle largeur vous avez regardé, deux enregistrements ne sont pas comparables. La méthode la plus saine consiste à mener les deux largeurs comme des séries distinctes : une série à une largeur desktop fixe, l'autre à une largeur étroite fixe.

Côté appareil, il existe une seconde distinction. Un proxy défini dans les paramètres Wi-Fi d'un appareil mobile ne couvre que ce réseau ; dès que vous passez aux données mobiles, le réglage est désactivé et la requête sort directement. Si vous mesurez avec un téléphone, vérifiez votre sortie avant chaque mesure, faute de quoi un de vos enregistrements sera avec proxy et l'autre sans.

La simulation d'appareil des outils de développement du navigateur est un compromis pratique : elle fixe la largeur de fenêtre et vous permet de mener deux séries sur la même machine. Mais la simulation ne reproduit pas le comportement réseau d'un téléphone réel ; si vous voulez voir la différence côté réseau, il faut mesurer avec un appareil réel. Pour les cas nécessitant une sortie depuis un réseau d'opérateur mobile, la page proxy mobile traite le sujet séparément.

Exploiter sa propre instance ou utiliser une instance publique

La différence entre les deux installations est moins technique qu'une différence de contrôle. Sur une instance publique, vous n'installez rien ; en contrepartie, vous ignorez quelles sources sont activées, d'où sortent les requêtes sortantes et comment le serveur limite les requêtes. La même instance peut être configurée différemment demain, sans aucun moyen pour vous de le remarquer.

Sur votre propre installation, en revanche, la configuration vous appartient : vous choisissez la liste des sources, vous écrivez les réglages de connexion sortante, vous activez le limiteur. En contrepartie, vous prenez en charge l'exploitation d'un serveur, le suivi des mises à jour et la manière dont l'adresse du serveur apparaît aux sources.

Si, sur votre propre installation, vous faites passer le trafic sortant par une seule sortie, n'oubliez pas que cette sortie s'adresse à toutes les sources avec la même adresse. Une série de requêtes intenses partant d'un seul serveur produit, côté source, un motif facilement identifiable. Il est possible de définir une sortie distincte par source, mais cela augmente la complexité et le coût de l'installation.

Si vous souhaitez rafraîchir les différences entre les installations orientées, différence entre forward proxy et reverse proxy l'article fournit un bon arrière-plan.

Configuration et validation : tester les deux liaisons séparément

Tester la première liaison est simple. Définissez la sortie sur votre profil de navigateur, ouvrez l'instance et vérifiez votre sortie. Sur cette liaison, un proxy HTTP comme un SOCKS5 fonctionne ; la différence apparaît selon l'endroit où le nom de domaine est résolu. Dans les configurations où la résolution se fait côté client, le nom de la cible est visible par votre résolveur local — détail où le DNS est-il résolu en SOCKS5 dans cet article.

Tester la seconde liaison n'est possible que sur votre propre installation. Après avoir défini le proxy de connexion sortante dans la configuration, vérifiez dans les journaux côté serveur que les requêtes vers les sources passent réellement par cette sortie. Si vous n'avez pas redémarré le service après avoir écrit la configuration, l'ancien réglage reste actif ; c'est l'erreur silencieuse la plus fréquente.

Côté navigateur, les trois contrôles de fuite restent standard : pour la résolution du nom de domaine Test de DNS leak, pour les interfaces du navigateur test de fuite WebRTC, pour les en-têtes ajoutés par le proxy test d'anonymat. Ce que signifient les niveaux d'en-tête niveaux d'anonymat est détaillée dans cet article.

Limites, coût et cadre d'usage approprié

Ce que cette couche apporte, c'est que votre requête ne parte pas directement de votre navigateur vers les moteurs sources. C'est une distinction précieuse, mais elle n'est pas illimitée. Les moteurs sources voient malgré tout une requête ; simplement, celle-ci provient d'une autre adresse. La promesse de confidentialité s'arrête à la couche réseau, elle ne couvre pas le reste du comportement de votre navigateur.

Le coût est le plus souvent faible. Les pages de résultats sont à dominante textuelle et, tant que vous laissez la catégorie images désactivée, le volume de données transféré reste limité. En revanche, rappelez-vous qu'une seule requête se transforme en plusieurs requêtes en arrière-plan : pour le calcul du quota, basez-vous non pas sur le nombre de recherches mais sur le nombre estimé de requêtes. Pour la méthode de calcul, calcul de bande passante .

Le cadre d'usage approprié est clair. Les conditions de service des moteurs sources et les directives robots.txt valent également pour les requêtes envoyées via une métacouche ; interposer une couche ne supprime pas cette obligation. Si vous envisagez une collecte de données à grande échelle, étudier les interfaces officielles est la première étape.

Enfin, tous les scénarios ne nécessitent pas de proxy. Si vous effectuez une recherche normale depuis votre propre pays, interposer une couche n'apporte rien ; vous n'ajoutez que de la latence et de la complexité. Le proxy prend son sens lorsqu'il s'agit de voir la surface de résultats d'un autre pays, de sortir d'un réseau d'entreprise avec une adresse fixe ou de rendre un dispositif de mesure reproductible.