Inside a Netlify function, 127.0.0.1 is the function’s own sandbox. A client built with the defaults connects to nothing there and throws NetworkException with ECONNREFUSED. Switch CapSkip to Server mode so it listens on your public IP, forward the port to the Windows machine if it sits behind a router, and allow the port through Windows Firewall.<\/p>\n
Then decide who may connect. By default the addresses Netlify functions connect from change as Netlify scales, so a firewall rule can’t list them. Netlify’s Private Connectivity gives functions a fixed set of IPs you can allow, but it is an add-on for Enterprise plans. Without it, the lock is CapSkip’s API Key Validation setting: switch it on, add a key for this site, and pass it as apiKey. Every SDK request carries the key, over plain HTTP like the rest of the call, so give the function a key of its own that you can delete without breaking anything else.<\/p>\n
Store the address and the key as environment variables in Netlify, under Project configuration, then Environment variables, with a scope that includes Functions. Two Netlify rules catch people out here. Variables declared in netlify.toml never reach functions at all. And each deploy keeps the values that were set when it was built, so a new CAPSKIP_HOST does nothing until you deploy again.<\/p>\n
\n
import { CapSkip } from "capskip";\n\n\/\/ The SDK does not read these by itself, so pass them in.\nif (!process.env.CAPSKIP_HOST) throw new Error("CAPSKIP_HOST is not set");\nconst solver = new CapSkip({\n apiKey: process.env.CAPSKIP_API_KEY, \/\/ a key from API Key Validation\n host: process.env.CAPSKIP_HOST, \/\/ your public IP, Server mode\n port: Number(process.env.CAPSKIP_PORT ?? 8080),\n});<\/pre>\n<\/div>\nKeep that check. If the variable is missing, host is undefined, and the SDK falls back to its default of 127.0.0.1 without a word, which puts you straight back at ECONNREFUSED. In the full example the check sits inside the solve’s try block, so a missing variable lands in the job record instead of stopping the function before it can write one.<\/p>\n
Step 2: solve and post in a background function<\/h2>\n
Setting background to true in the function’s config is all it takes to make one. This one checks a shared secret, because its URL is public and every request to it makes your solver work. Then it fetches the page, reads the sitekey and solves:<\/p>\n
\n
\/\/ netlify\/functions\/solve-signup.mjs\nimport { getStore } from "@netlify\/blobs";\nimport * as cheerio from "cheerio";\n\/\/ solver from Step 1; PAGE_URL is the page with the CAPTCHA.\n\nexport default async (req) => {\n if (req.headers.get("x-job-secret") !== process.env.JOB_SECRET) return;\n const { jobId, email } = await req.json();\n const jobs = getStore({ name: "captcha-jobs", consistency: "strong" });\n\n const page = await fetch(PAGE_URL);\n const $ = cheerio.load(await page.text());\n const result = await solver.recaptcha($(".g-recaptcha").attr("data-sitekey"), PAGE_URL);\n \/\/ Then claim the job and post the form, below.\n};\n\nexport const config = { path: "\/api\/solve-signup", method: "POST", background: true };<\/pre>\n<\/div>\nThe answer for reCAPTCHA is in result.code. Use it at once: with a two minute lifetime, the run that solves is the run that posts.<\/p>\n
Now the retries. When a background function ends in an error, Netlify runs it again one minute later, and if that fails too, once more two minutes after that. Before the form is posted, a retry is exactly what you want: a fresh page and a fresh solve. After the form is posted, a retry is a second signup. So the function claims the job in Blobs before it posts:<\/p>\n
\n
\/\/ Only one run can create this key, so only one run posts.\nconst claim = await jobs.setJSON(`${jobId}-posted`, { at: Date.now() }, { onlyIfNew: true });\nif (!claim.modified) return;\n\nconst form = $("form").has(".g-recaptcha");\nconst body = new URLSearchParams(form.serializeArray().map((f) => [f.name, f.value]));\nbody.set("email", email);\nbody.set("g-recaptcha-response", result.code);\nconst cookie = page.headers.getSetCookie().map((c) => c.split(";")[0]).join("; ");\n\nconst res = await fetch(new URL(form.attr("action") || PAGE_URL, PAGE_URL), {\n method: "POST",\n headers: { cookie, referer: PAGE_URL },\n body,\n});\nawait jobs.setJSON(jobId, { state: "done", status: res.status });<\/pre>\n<\/div>\nWith onlyIfNew, the write succeeds only if the key does not exist yet, and modified says whether this run created it. Two runs racing for the same job can’t both get true, so only one of them posts. The function also checks for that key before it starts, so a rerun of a finished job returns without spending a solve.<\/p>\n
The post itself sends the page’s cookies and the form’s own fields, a hidden CSRF token included, which is what most signup forms check besides the CAPTCHA. It also sends the page as Referer, because fetch sends none and some frameworks refuse an HTTPS form post without it. Once the claim is taken, record any failure in Blobs instead of throwing. A retry would stop at the claim, so throwing buys nothing, and the record is the one place your status endpoint can show the error. The full example below wraps both phases this way.<\/p>\n
Step 3: start jobs and read their results<\/h2>\n
Start a job from any server-side code by posting to the background function. The caller makes up the job id, because a 202 has no body to carry one back:<\/p>\n
\n
const jobId = crypto.randomUUID();\nconst start = await fetch("https:\/\/YOUR_SITE.netlify.app\/api\/solve-signup", {\n method: "POST",\n headers: { "x-job-secret": process.env.JOB_SECRET },\n body: JSON.stringify({ jobId, email: "YOUR_EMAIL" }),\n});\nconsole.log(start.status); \/\/ 202: accepted, not solved yet<\/pre>\n<\/div>\nA small synchronous function reports the record. It runs in milliseconds, far inside the 60 second limit:<\/p>\n
\n
\/\/ netlify\/functions\/job-status.mjs\nimport { getStore } from "@netlify\/blobs";\n\nexport default async (req, context) => {\n const jobs = getStore({ name: "captcha-jobs", consistency: "strong" });\n const job = await jobs.get(context.params.id, { type: "json" });\n if (!job) return new Response("unknown or not started", { status: 404 });\n return Response.json(job);\n};\n\nexport const config = { path: "\/api\/jobs\/:id", method: "GET" };<\/pre>\n<\/div>\nPoll it every few seconds. A job has no record until it finishes or an attempt fails, so a 404 means its first attempt is still running, or that it never started because the secret did not match. Read with strong consistency, as here. Blobs is eventually consistent by default: a new record shows up at once, but an update can take up to 60 seconds to reach every edge location, long enough to show a job that has since finished as still retrying.<\/p>\n
To run the job on a timer, reach for a scheduled function, but mind its limit: 30 seconds, half the synchronous one. Let it hand the work to the background function and finish in well under a second:<\/p>\n
\n
\/\/ netlify\/functions\/nightly-signup.mjs\nexport default async () => {\n const res = await fetch(`${process.env.URL}\/api\/solve-signup`, {\n method: "POST",\n headers: { "x-job-secret": process.env.JOB_SECRET },\n body: JSON.stringify({ jobId: crypto.randomUUID(), email: "YOUR_EMAIL" }),\n });\n console.log("queued:", res.status); \/\/ 202 means accepted, not solved\n};\n\nexport const config = { schedule: "@daily" };<\/pre>\n<\/div>\nURL is one of the read-only variables Netlify gives functions at runtime: your site’s main address. Scheduled functions fire only on published deploys, not on Deploy Previews or branch deploys.<\/p>\n