LogRocket: script could not load. Check that you have a valid network connection.

By Ohad Krispin, founder of VibeRaven · LinkedIn

"LogRocket: script could not load. Check that you have a valid network connection." is a console warning from the logrocket npm package. It prints when the script element that loads LogRocket's logger reports an error, so the browser did not get the file: the usual causes on LogRocket's troubleshooting page are a Content-Security-Policy that lacks LogRocket's hosts and a browser extension or network policy that blocks the script. The package then stops recording, so no sessions arrive. Allow the hosts from LogRocket's CSP example in script-src and connect-src, or proxy LogRocket through your own domain with _lrAsyncScript and serverURL. A second warning, "LogRocket: script execution has been blocked by a product or service.", means the script loaded but did not run. Reproduced with logrocket 12.4.0 on 2026-10-31.

Which Content-Security-Policy entries does LogRocket need?

LogRocket's troubleshooting page gives this header as its example. Merge its hosts into your own script-src and connect-src instead of replacing your policy, and keep 'self' where you need it, because the example's connect-src does not list it. In logrocket 12.4.0 the package code points at cdn.logr-in.com for the logger script and r.logr-in.com for recording data, both covered by the entries below. Another package version may use another host from the list, so copy the whole list from the page.

Content-Security-Policy: child-src 'self' blob:; worker-src 'self' blob:;
script-src 'self' https://cdn.logrocket.io https://cdn.lr-ingest.io https://cdn.lr-in.com https://cdn.lr-in-prod.com https://cdn.lr-ingest.com https://cdn.ingest-lr.com https://cdn.lr-intake.com https://cdn.intake-lr.com https://cdn.logr-ingest.com https://cdn.lrkt-in.com https://cdn.lgrckt-in.com https://cdn.logr-in.com;
connect-src https://*.logrocket.io https://*.lr-ingest.io https://*.logrocket.com https://*.lr-in.com https://*.lr-in-prod.com https://*.lr-ingest.com https://*.ingest-lr.com https://*.lr-intake.com https://*.intake-lr.com https://*.logr-ingest.com https://*.lrkt-in.com https://*.lgrckt-in.com https://*.logr-in.com

How do I tell a CSP block from an ad blocker?

The package prints the first warning when the logger script element reports a load error, and the second when the script loaded but never defined the logger. A comment in the package code says Brave can do the second: it loads the script and blocks its execution. The warning alone does not name the cause. Open the Network tab, find the request for the logger script and read its status, then repeat in a private window with extensions off. If it loads there, an extension or a network policy was blocking it. LogRocket's page says to check the console for errors when you suspect the policy.

logger script answers 404:
LogRocket: script could not load. Check that you have a valid network connection.

logger script answers 200 but defines no logger:
LogRocket: script execution has been blocked by a product or service.

Can I proxy LogRocket through my own domain on Vercel?

LogRocket documents proxying through your own domain: one proxy for scripts (GET requests, from cdn.logrocket.com) and one for recording data (POST requests, to r.logrocket.com). A plain CNAME does not work, its page says a Cloudflare proxy cannot forward to LogRocket at this time, and it links a CloudFront guide that LogRocket tested. For the npm package, set window._lrAsyncScript to your script URL before the first import of LogRocket, and pass serverURL to init. We checked that _lrAsyncScript becomes the src of the script tag the package adds. Vercel's docs show a rewrite from a path to an external site in vercel.json, but LogRocket's docs do not mention Vercel, so test a rewrite end to end before you rely on it. Your CSP then needs your proxy hosts, because those are the hosts the browser contacts.

window._lrAsyncScript = "https://logrocket-cdn.example.com/logger.min.js";

LogRocket.init("YOUR_APPLICATION_ID", {
  serverURL: "https://logrocket-data.example.com/i",
});

Checklist

How to fix it, then check the fix

01Open the deployed site, then the browser console, and note which of the two LogRocket warnings appears.

Read the Content-Security-Policy your deployment sends:

curl -sI https://YOUR-APP.vercel.app | grep -i content-security-policy

03If the header exists, add the LogRocket hosts from the example above to its script-src and connect-src, in next.config.js headers() or in vercel.json headers, then redeploy.
04In a private window with extensions off, load the site again. If the warning goes away there, an extension was blocking the script; for users you cannot reach, proxy LogRocket through your own domain.
05
After the fix, run this in the console. A string means LogRocket loaded; null or undefined means it did not. Wait a few seconds after the page opens:
```
window.LogRocket && window.LogRocket.sessionURL
```

Sources

Official docs behind this checklist

More provider errors

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Do I need worker-src in the policy?

The LogRocket example includes child-src and worker-src with blob:. The page warns that worker-src is not supported in Safari and mobile Safari before 15.5, and that using it there may stop LogRocket from running.

Does the warning mean my network is down?

No. The text says to check your network connection, but the code prints it for any load error on the script element. In our run, a local server that answered 404 for the script produced it.

Do I still need CSP entries after I proxy LogRocket?

If your site sends a Content-Security-Policy, yes, for your own proxy hosts: the browser then contacts those hosts, so allow them in script-src and connect-src. LogRocket's proxy page does not cover CSP.