This proxy has an API key. Enter it once; this browser remembers it.
It may be restarting. This page keeps trying.
- Holding up
- Browser on
What should I do?
When something stops the proxy — a CAPTCHA, Google's sign-in, or a page that is not what was asked for — it shows up here with Solve from phone, Check again and Let it through.
No fetches yet.
Silences every alert — CAPTCHA, sign-in and unexpected page: the sound on the proxy PC, the phone push, and the flashing banner — and stops the browser window being raised over whatever is on screen. Parsing is not affected: the browser still parks on the page and waits for you indefinitely, so an overnight run with alerts off stops quietly and carries on the moment you deal with it in the morning. Turning this off while something is waiting alerts straight away.
What it skips, and what it never touches
Profile photos, co-author photos and icons are refused before they download, on the pages whose page check below has Skip images ticked (all three built-in ones). The parsers read only the HTML, so nothing they get changes; the browser window on the proxy PC shows those pages without pictures.
Expect a small saving. Nearly all of what a Scholar page costs is its HTML, styles included. The icons and placeholders every page shares come from the cache after the first page, so what the saver really trims is each scholar's own photo, and only once per scholar. Compare the average a page below with the switch on and off.
A CAPTCHA, Google's sign-in and any page no rule covers always load in full, and nothing is skipped while the proxy is stopped on a page, so a challenge is never missing its pictures.
Stylesheets and scripts are left alone. The browser keeps them in its cache (the table shows how many come from it), so after the first page they cost next to nothing, and a page that never runs its scripts looks more like a bot to Google.
How the checks work
Before a page is handed over, the first rule below whose pattern matches the requested URL says what a real answer contains: the element the parser reads. A page without it — Google's sign-in, a consent screen, an error page, a Scholar redesign — stops the proxy exactly like a CAPTCHA: the parser pauses, no data is touched, and you are alerted. Nobody has to have seen that page before. Requests no rule matches are only checked for leaving Scholar. A page with an error status (a 404 for a removed profile) is never stopped; the parsers handle those. CAPTCHAs and Google's sign-in are caught even with this switched off.
If the proxy stops on a page that is actually fine, fix its rule here (or switch the rule off) and that same request goes through: within a few seconds the proxy re-checks the page, finds it passes, and lets the waiting parser carry on. Let it through on the Home page is for a one-off page.
Only needed if the proxy has one configured. Kept in this browser only.
Scholar's Citations pages need a signed-in browser. This shows the sign-in as the proxy's own fetches reveal it — a Scholar page with the account menu means signed in, a fetch sent to Google's sign-in page means signed out — so it never makes an extra request. The sign-in is kept across restarts. Log in to Google opens Google's sign-in in the proxy's browser window on the PC (or, while the proxy is stopped on a sign-in page, shows that page); from a phone, use Solve from phone on Home.
These act on the worker Chromium window the proxy drives, not on this page. Remote view streams it to this device and forwards taps and typing.
Same Wi-Fi as the proxy PC. If a link times out, allow TCP 8800 through Windows Firewall.
Query style
Prefix style