Un délai d'expiration sur waitForSelector signifie que l'élément attendu n'a pas satisfait sa condition d'attente. L'ajout d'un proxy avant son apparition ne prouve pas que la connexion TCP du proxy a expiré.

  1. Conservez les preuves de navigation. Notez l'URL finale, le statut de la réponse principale et les requêtes en échec pertinentes avant l'attente du sélecteur. Dans Puppeteer, une réponse HTTP d'erreur n'est pas nécessairement levée comme exception de navigation.
  2. Inspectez le document livré. Son titre ou une capture d'écran soigneusement masquée peut révéler un défi de connexion, une page d'accès refusé ou une autre page régionale. La page visée a peut-être aussi subi des requêtes d'application en échec ; vérifiez également le sélecteur et le cadre.
  3. Traitez tout défi à sa source. Configurez l'authentification proxy prise en charge avant la navigation pour un défi du proxy. Un défi de destination relève du flux de travail autorisé de l'application, avec ses propres identifiants.

Cela met souvent au jour des preuves utiles qui existaient avant que l'attente d'élément ne devienne la première exception signalée par votre code. Fournir un mot de passe de site web au proxy ne peut pas corriger ce document antérieur.

Choisissez le minuteur après avoir identifié l'opération en échec. La navigation, la configuration réseau et les attentes d'éléments ont des limites différentes. Une interface réellement lente peut justifier une attente de sélecteur plus longue ; une page d'erreur restera le mauvais document.

Gardez la session du navigateur et la route stables pendant la comparaison. Changer le proxy, le sélecteur et tout l'état du navigateur en une seule tentative masque quelle condition comptait.

Articles similaires