یک نشست Chromote با یک فرایند Chrome گفتگو می‌کند. درخواست‌های مرورگر آن از پیکربندی پروکسی همان فرایند پیروی می‌کنند، پس آرگومان‌ها را پیش از ساختن آن تعیین کنید:

args <- c(
  chromote::get_chrome_args(),
  "--proxy-server=http://proxy.example:8080"
)
browser <- chromote::Chrome$new(args = args)
controller <- chromote::Chromote$new(browser = browser)
session <- chromote::ChromoteSession$new(parent = controller)

این کار آرگومان‌های پیش‌فرض موجود Chromote را نگه می‌دارد و شنونده HTTP را اضافه می‌کند؛ یک نقطه پایانی از فهرست پروکسی HTTP می‌تواند نشانی نمونه را برای مرور عمومی مجاز پر کند. تنها زمانی به‌جای آن از نشانی socks5 استفاده کنید که نقطه پایانی واقعاً SOCKS5 صحبت کند. هنگام چیدن بردار آرگومان‌ها، یک کلید پروکسی موجود متضاد را بردارید.

عملیات CDP موردنظر را از طریق session انجام دهید، سپس نشست، کنترل‌کننده و مرورگر متعلق به خود را به‌عنوان بخشی از پاک‌سازی بار کاری R ببندید. مسیر پاک‌سازی R به سبک try/finally اگر ناوبری خطا بدهد سودمند است.

برای برنامه‌هایی که از مرورگر پیش‌فرض مشترک Chromote استفاده می‌کنند، set_chrome_args پیش‌فرض‌ها را برای ساخت مرورگر در آینده تغییر می‌دهد. فرایند موجود را دوباره راه‌اندازی نمی‌کند. ساختن یک شیء Chrome صریح، مانند بالا، مالکیت و زمان آغاز را دیدنی می‌کند.

محیط http_proxy یا https_proxy خود R می‌تواند یک دانلودکننده R را بدون تغییر این مرورگر پیکربندی کند. به همین ترتیب، تغییر مسیر Chrome یک فراخوانی API جداگانه R را پیکربندی نمی‌کند. مشخص کنید کدام سمت اتصال CDP درخواست را می‌فرستد.

مقالات مرتبط