Skip to content

v0.4.33 — a stricter, more exact connection limit

Choose a tag to compare

@github-actions github-actions released this 19 Oct 18:53
· 4 commits to main since this release

Free open-source Google SERP parser and rank tracker, powered by BlankTrail Proxy.

A stricter, more exact connection limit.

What changed since 0.4.32

  • The service's solves are matched to the parser's port by port. A solve
    BlankTrail runs on a port where the parser has a request waiting is that
    request's solve, counted once; one on a port the parser has left is a solve
    nobody waits for, and holds a reserve of its own. 0.4.32 let new sessions
    start beside such leftover solves without counting them, which could take a
    profile over its limit when those sessions met checks too.
  • A new session waiting too long is no longer passed by. Once a request
    for a fresh session has waited ten seconds, ordinary searches stop taking the
    places ahead of it — unless the room it needs is held by something the
    parser cannot give back (another program on the same profile, connections
    the service keeps), in which case nothing is held back for it.
  • Sessions being kept warm, and a request the parser carries to another
    address, are counted as the possible solves they are.
  • How many connections a request costs is learned more accurately while
    checks are being solved.
  • The start of a job on a limited profile is slower than in 0.4.32. On our
    stand, 20 threads at a limit of 30 with the reserve of 5: the limit held
    (four seconds above it at most, peak 33), no query failed, and the job took
    9 min 9 s against 6 min 49 s for 0.4.32 in an hour with twice as many checks
    — six checks at once fill a limit of 30, and no new session starts until
    one of them is solved. A larger limit, or a smaller Reserve for solving a
    captcha
    if your solver opens fewer connections, starts more at once.
  • A profile without a limit behaves exactly as before.

This build needs nothing installed. On Windows it is one file: download
gserp.exe, put it anywhere, double-click it. The console goes away, an icon
appears in the notification area and your browser opens at
http://127.0.0.1:8080. Everything the interface needs is inside that file, and
it keeps its history in a gserp.db beside itself. It listens on this machine
only.

On Linux and macOS, unpack the archive for your system and run ./start.sh.

It does need BlankTrail Proxy with a licence including Challenge Breaker.
Google serves a JavaScript shell — zero results — to any plain HTTP client, no
matter how many proxies are behind it; results appear only after the solver has
carried the session through the challenge.

Which file

System File
Windows, ordinary PC gserp.exe — the whole program, nothing to unpack
Windows on ARM gserp-arm64.exe
Linux, ordinary PC or server gserp-linux-amd64.tar.gz
Linux on ARM gserp-linux-arm64.tar.gz
Mac with Apple silicon (M1 and later) gserp-macos-apple-silicon.tar.gz
Mac with an Intel processor gserp-macos-intel.tar.gz

The archives hold the program, a starter script, both READMEs and the licence.
The zipped Windows builds are here too, for whoever wants the READMEs beside
the program.

Asset names carry no version, so a link to
releases/latest/download/<name> always fetches the newest build. Which
version you have is what gserp version prints.

Upgrading from 0.4.31 or 0.4.32: replace the program and start it; nothing in the history changes.

Upgrading from 0.4.2 – 0.4.30: replace the program and start it. The
history moves to schema version 34 on the first start; a copy of the database
before it costs nothing.

Upgrading from 0.4.0 or 0.4.1: replace the program and start it. The
history moves to schema version 34 on the first start — the jobs table is built
again to take the new filter — which on ten million results took a few
seconds. A copy of the database before the first start costs nothing.

Upgrading from 0.3.0 or older: replace the program and start it. The
history moves to schema version 34 on the first start — the jobs table is built
again so it can hold the new kind — and no setting has to be filled in again.
On a history of ten million results this took a few seconds; a copy of the
database before the first start costs nothing and is worth having.

Windows will warn about it

SmartScreen judges a program by the reputation of whoever signed it, and these
builds are unsigned: there is no certificate to have a reputation, so the
warning is not something the build can avoid. More info -> Run anyway.

What can be checked is that the file you have is the file published here.
SHA256SUMS.txt is beside the downloads:

Get-FileHash .\gserp.exe -Algorithm SHA256          # Windows
sha256sum -c SHA256SUMS.txt                         # Linux
shasum -a 256 -c SHA256SUMS.txt                     # macOS

Windows also marks anything downloaded, which is what raises the prompt.
Unblock-File .\gserp.exe clears it, once, per file.

macOS keeps downloaded programs quarantined in the same way. If it refuses to
open the file, clear the mark once with xattr -d com.apple.quarantine gserp in
the unpacked folder.

What the program does

  • Four kinds of job: parsing, position check, index check and search
    suggestions. Organic results, ads and related queries, each exportable on
    its own, laid out field by field.
  • Browser interface in English and Russian, light or dark, with a walk through
    it for whoever has just installed it.
  • Proxy profiles: named sets of exits — a file, a URL, or the VPN gateways a
    BlankTrail subscription carries — optionally behind a first hop, with a job
    naming the one it goes out through.
  • Sessions of its own: Google identities kept with their cookies and their
    address, rested between requests and written down as they go.
  • Exports as CSV, JSON Lines and TXT; deduplication by URL or by host.
  • HTTP API under /api/v1/, and a SerpApi-compatible GET /search a program
    written against that service reaches by changing the base address alone.

Measured on a live fifteen-thousand-address list with result addresses kept:
about 1100 pages a minute at a hundred threads, 30–40 captchas per thousand
pages once the start's wave of checks has passed. The start is the slow part — every session that rested between jobs is
checked again on its first request — and that is the shape to expect.

Full documentation: README
· по-русски

MIT licence. Provided as is, without warranty; observing the terms of service
of the sites you point it at, and the law where you are, is yours.