Puppeteer-ის პროქსის ტაიმაუტების დიაგნოსტიკა მოთხოვნისა და გვერდის ეტაპის მიხედვით

გამოიყენეთ requestfailed ქსელური ხარვეზებისთვის და HTTPResponse-ის სტატუსი სერვერის პასუხებისთვის, სანამ პროქსის დაადანაშაულებთ ნელი სრული გვერდის ნავიგაციის გამო.

სწრაფი პასუხი curl-იდან ან Axios-იდან ჩვეულებრივ ერთი რესურსია. Puppeteer-ს ასევე შეუძლია სკრიპტების, სურათების, ჩარჩოებისა და API-ების მოტანა რამდენიმე ჰოსტიდან და უფრო გვიანი გვერდის ეტაპის ლოდინი.

ვინაიდან პროქსი უკვე კონფიგურირებულია არსებულ გვერდზე, დააკვირდით ცალკეულ ხარვეზებს ნავიგაციის დროს:

page.on("requestfailed", request => {
  console.log(request.url(), request.failure()?.errorText);
});

await page.goto(targetUrl, {
  waitUntil: "domcontentloaded",
  timeout: 30000,
});

გაუშვით ეს async სამუშაო ნაკადში რეალური targetUrl-ით. მაგალითი ელოდება DOMContentLoaded-ს, რაც ხდება უფრო ადრე, ვიდრე ყოველი საჭირო სურათის ან უფრო გვიანი აპლიკაციის პასუხის დასრულება. შეადარეთ ეს ეტაპი იმას, რისაც საწყისი ნავიგაცია ელოდა: მთავარი დოკუმენტი, DOM, load ან ქსელის სიჩუმე სხვადასხვა შედეგია.

403 ან 500 პასუხი არ არის requestfailed მოვლენა. წაიკითხეთ სტატუსი HTTPResponse-ის მეშვეობითაც.

გამოიყენეთ დაკვირვებები ნელი ან უარყოფილი რესურსის, განმეორებითი ავტენტიფიკაციის ან უფრო გვიანი ლოდინის პირობის გამოსავლენად. უფრო გრძელი ტაიმაუტი მხოლოდ აგრძელებს ლოდინს; ის არ ამცირებს ბრაუზერის მუშაობას და არ ამტკიცებს, რომ ყოველი რესურსის კავშირი მიღებულია.

დაკავშირებული სტატიები