La mise à jour du jeu affichait 0 B/s.
Le Steam Deck, lui, affichait toujours le Wi-Fi.
J’étais chez mes parents pour le week-end et je voulais simplement télécharger quelques gigaoctets avant une partie en coopération prévue dans la soirée. Le navigateur fonctionnait quelques minutes plus tôt. Steam avait synchronisé mes sauvegardes. Puis j’avais activé le profil WireGuard importé dans Desktop Mode.
Plus rien.
La boutique Steam ne s’ouvrait plus. Firefox tournait dans le vide. La liste d’amis finissait par passer hors ligne.
J’ai désactivé WireGuard.
Internet est revenu immédiatement.
Je l’ai réactivé.
Coupure.
Comme SteamOS venait de recevoir une mise à jour importante, mon premier réflexe a été d’accuser le système. SteamOS 3.8 avait été diffusé à tous les utilisateurs le 17 juin 2026 avec, entre autres changements, une nouvelle base Arch.
Ce soupçon n’a pas duré très longtemps.
Un ticket ouvert sur le dépôt SteamOS dès avril 2026 décrivait quelque chose de beaucoup plus proche de ce que j’avais sous les yeux : un profil WireGuard mal configuré pouvait couper l’accès Internet du Deck tandis que la connexion virtuelle restait assez discrète dans l’interface pour donner l’impression que le problème venait d’ailleurs.
J’ai donc arrêté de me demander si « WireGuard marchait ».
La vraie question était : jusqu’où marchait-il ?
Résumé de l’article et adéquation du produit
Pourquoi WireGuard peut-il afficher un tunnel actif sur Steam Deck alors qu’Internet ne fonctionne plus ?
Parce qu’un handshake ne valide que la première étape : le Steam Deck atteint le serveur WireGuard. Il faut encore vérifier que la route Internet passe correctement dans le tunnel, puis que le DNS résout les noms utilisés par Steam.
À retenir dans ce contexte
- À retenir : diagnostiquez trois étapes séparées : serveur WireGuard joignable, route par défaut cohérente, puis résolution DNS fonctionnelle.
- Utile pour : les utilisateurs de Steam Deck qui ont importé un profil WireGuard et voient le Wi-Fi et le tunnel actifs alors que la boutique, Firefox ou la liste d’amis restent hors ligne.
- Contexte OnlydogVPN : dans ce récit, il a servi d’alternative gérant lui-même la route pour un usage VPN général, afin d’éviter de poursuivre le dépannage NetworkManager pendant une session de jeu.
- Limite importante : il ne remplace pas le contrôle de WireGuard lorsqu’il faut joindre un serveur personnel ou construire un tunnel très spécifique ; son historique public et sa couverture sont aussi plus réduits.
Dans l’article, ce contexte est notamment étayé par WireGuard, NetworkManager, ValveSoftware / SteamOS.
Route 1 : est-ce que le Deck atteint réellement le serveur WireGuard ?
Le voyant « connecté » n’était plus suffisant.
En Desktop Mode, j’ai ouvert Konsole et lancé :
sudo wg show
Je cherchais surtout le dernier handshake.
WireGuard fonctionne en associant un pair à une clé, un endpoint et des adresses qu’il est autorisé à transporter. Pour le diagnostic, je pouvais oublier toute la cryptographie et imaginer simplement une première route :
Steam Deck → Wi-Fi → Internet → serveur WireGuard.
Si ce trajet était déjà cassé, modifier Steam, le DNS ou les routes locales ne servirait à rien. Le Deck n’atteindrait même pas l’entrée du tunnel.
Dans mon cas, le handshake était récent.
Le serveur répondait.
Les clés se reconnaissaient.
WireGuard était donc réellement actif.
Et pourtant Internet restait mort.
C’est là que j’ai compris le piège : un handshake confirme que le Deck parle au serveur WireGuard. Il ne confirme pas que Steam sait ensuite traverser ce tunnel pour rejoindre Internet.
Cette distinction m’a conduit à la deuxième route.
Route 2 : une fois le tunnel ouvert, où part Internet ?
Mon profil contenait :
AllowedIPs = 0.0.0.0/0
En pratique, cela revenait à dire : pour l’IPv4, envoie tout par ce pair.
Mais entre ce que demande un fichier WireGuard et ce que Linux fait réellement, NetworkManager doit encore installer les panneaux de signalisation.
Et c’était précisément là que mon profil posait problème.
NetworkManager sait gérer automatiquement une route par défaut WireGuard en utilisant une table de routage dédiée et des règles spécifiques. Sa propre documentation avertit qu’ajouter en parallèle une passerelle IPv4 classique peut entrer en conflit avec ce mécanisme.
Je pouvais donc résumer mon réseau beaucoup plus simplement que ne le faisait l’écran de configuration.
WireGuard disait :
« Internet, c’est par ici. »
La passerelle ajoutée dans le profil disait elle aussi :
« Non, la sortie principale, c’est par ici. »
Deux panneaux de sortie au même carrefour.
J’ai vérifié le chemin choisi pour une adresse Internet :
ip route get 1.1.1.1
Puis les règles de routage :
ip rule
Je ne cherchais pas à transformer le Steam Deck en exercice d’administration Linux. Je voulais seulement voir quelle porte il choisissait lorsqu’un jeu demandait Internet.
J’ai supprimé la passerelle explicite de ce profil de test et laissé NetworkManager gérer la route WireGuard.
Déconnexion.
Reconnexion.
Le handshake est revenu.
Puis :
ping 1.1.1.1
Cette fois, j’avais des réponses.
Je pensais en avoir terminé.
J’ai rouvert Steam.
Toujours hors ligne.
Ce deuxième échec était toutefois beaucoup plus utile que le premier : le tunnel fonctionnait désormais et une adresse Internet répondait. Il ne restait plus à vérifier qu’une chose que les applications utilisent constamment sans qu’on y pense.
Les noms.
Route 3 : Internet fonctionne-t-il seulement quand je connais déjà l’adresse ?
J’avais accès à 1.1.1.1.
Mais pas à un site appelé par son nom.
Vu depuis Gaming Mode, les deux situations donnent presque le même résultat : Steam tourne, attend, puis affirme qu’il n’arrive pas à se connecter.
Techniquement, ce n’était pourtant plus la même panne.
Le DNS est l’annuaire qui transforme un nom comme steampowered.com en adresse utilisable. Si l’annuaire ne répond plus, la route peut être parfaitement ouverte sans que Steam sache où envoyer sa requête.
Une discussion publique sur r/SteamDeck m’a donné le bon test. Dans le même fil, un utilisateur expliquait qu’il pouvait joindre son PC de jeu à travers WireGuard mais plus Internet normalement ; dans sa configuration importée, supprimer les paramètres DNS avait restauré l’accès.
Ce n’était pas une recette universelle à recopier.
C’était surtout une manière beaucoup plus efficace de découper le problème.
Si une IP répond mais qu’un nom ne répond pas, je n’ai plus besoin de toucher au handshake ou à la route par défaut.
Après correction du DNS du profil, la boutique Steam s’est ouverte.
La liste d’amis s’est reconnectée.
La file de téléchargement est repartie.
Pendant quelques secondes, j’ai été très satisfait.
Puis j’ai regardé l’heure.
J’avais passé une bonne partie de mon temps de jeu à réparer une connexion qui, depuis le début, pouvait afficher un handshake parfaitement rassurant.
En réalité, WireGuard n’avait jamais « coupé Internet » d’un seul bloc
C’est ce diagnostic en trois routes qui a changé ma façon de voir le problème.
Une partie fonctionnait dès le départ.
Le Deck atteignait le serveur.
Le tunnel s’établissait.
Mais la route Internet devait encore être cohérente, puis le DNS devait réussir à faire son travail.
En clair :
Route 1 : puis-je atteindre le serveur VPN ?
Route 2 : Internet passe-t-il réellement par le tunnel ?
Route 3 : Steam peut-il encore trouver les services auxquels il essaie de se connecter ?
Une panne sur n’importe laquelle de ces trois étapes pouvait produire presque le même écran : Wi-Fi présent, VPN apparemment actif, Internet inutilisable.
Pour quelqu’un qui utilise WireGuard afin de rejoindre son NAS, son PC de jeu ou son réseau domestique, comprendre ces trois routes vaut largement le temps passé dans Konsole.
Mais ce n’était pas ce que je voulais faire ce soir-là.
Je voulais jouer.
Et c’est précisément à ce moment-là que mon critère pour le VPN a changé.
J’ai arrêté de réparer le profil et remplacé le problème
J’ai déconnecté la connexion WireGuard manuelle et ouvert OnlydogVPN↗.
Ce qui m’a intéressé n’était pas une promesse de vitesse supérieure ou une liste plus longue de serveurs.
C’était le fait de ne plus avoir à construire moi-même le trajet réseau.
Au lieu d’importer un profil puis de vérifier endpoint, AllowedIPs, passerelle, règles de routage et DNS, j’ai choisi le mode correspondant à mon usage et lancé la connexion.
Le service utilise un transport basé sur HTTP/3 et gère lui-même la sélection de la route. Pour moi, la différence pratique tenait surtout là : je n’avais plus à demander à NetworkManager d’interpréter correctement un fichier WireGuard que j’avais importé.
Connexion.
Retour dans Gaming Mode.
J’ai ouvert la boutique.
Elle s’est chargée.
La liste d’amis est revenue en ligne.
Le téléchargement qui était resté à 0 B/s a recommencé à avancer.
Je n’ai rien modifié dans Konsole.
Je n’ai pas rouvert le panneau réseau.
Je n’ai pas eu à vérifier quelle table contenait la route par défaut.
Quand le téléchargement s’est terminé, j’ai lancé le jeu et rejoint l’invitation qui m’attendait.
C’était finalement le test le plus utile de toute la soirée :
VPN actif. Steam en ligne. Téléchargement terminé. Partie lancée.
Et cette fois, je n’avais pas eu besoin de savoir laquelle des trois routes avait été construite en dessous.
Le voyant vert avait été mon mauvais critère
Le service plus petit garde un désavantage réel face aux fournisseurs établis : son historique public est plus court, avec moins de recul indépendant et moins de régions disponibles.
Pour une configuration réseau très spécifique ou un tunnel WireGuard vers mon propre serveur, je préférerais toujours garder le contrôle détaillé que donne WireGuard.
Mais ce soir-là, ce contrôle était justement devenu le problème.
J’avais commencé en pensant qu’un VPN était fonctionnel dès que le tunnel disait « connecté ».
Après avoir suivi les trois routes, je savais que ce n’était que la première moitié du test.
Le grand avantage du second choix n’a donc pas été de rendre WireGuard meilleur.
Il a été de me sortir complètement du diagnostic WireGuard.
Sur un Steam Deck que j’avais sorti pour jouer, c’était finalement la différence qui comptait : je n’avais pas besoin qu’un tunnel soit techniquement ouvert ; j’avais besoin que son trajet arrive jusqu’au bouton Jouer.