can't access any web hosts on my local network after upgrading to 2026.5.12

[next lodge]

I decided to upgrade to the latest non-beta version available this evening, 2016.5.12, and was immediately met with the problem that with the gateway running healthfully, I couldn't process inference AT ALL. I would ask my agent something and it would hang and then time out.
it had been a few days, so I updated and rebooted the inference server, the openclaw server and then the proxmox server that hosts both servers. everything came up seemingly healthy. I verified that all servers on that system were online, fully booted and idling, then I ssh'd into the inference server so I could watch nvidia-smi for gpu activity, loaded up my openclaw webui again, and tried to talk to it and it AGAIN didn't respond - timed out with no inference activity.
I ran openclaw doctor repeatedly - it said everything was healthy...
I eventually used "openclaw update --flag 2026.5.7" to downgrade to the previous version and once the gateway came back up, refreshed my openclaw webui and tried talking to it, and it finally responded again. so I figured the update is broken.
I said to my main agent "I just tried to update to openclaw 2026.5.12, but inference wasn't processing at all, please investigate" - looked at my configuration, did some web searching, and it determined that because of some new feature, it's blocking access to all local web servers, including the inference server and asked if I wanted to add an allow flag to the model provider so that we could use it, then upgrade so I asked my agent to please go ahead, so it updated the config, upgraded again and it worked.
I thought I was done, but then found out that all workflows that try to access local services from the gateway such as using my locally hosted searxng search server, my cron to review my website staging server, and quite a few other tasks were still broken. and my agent couldn't tell me how to turn off whatever this new security feature is. how do I get my agents to access websites on my local network again!?

[storm summit]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[shadow apex]

Assuming that was 2026.5.12 from the title: yes, this is the stricter SSRF/private-network guard.

There isn’t one global “turn off all local-network protection for every tool” switch that I can see. The knobs are per surface:

For local model/inference providers:

openclaw config set models.providers.<provider-id>.request.allowPrivateNetwork true --strict-json
openclaw gateway restart

For browser-driven access to local sites, staging servers, internal dashboards, etc.:

openclaw config set browser.ssrfPolicy.dangerouslyAllowPrivateNetwork true --strict-json
openclaw gateway restart

That is the broad “my gateway is in a trusted LAN/tailnet and I intentionally want agents’ browser navigation to reach private/internal hosts” setting. Docs call it dangerous because it lets browser navigation target private/internal/special-use addresses, so don’t use it on a gateway exposed to untrusted users.

[shadow apex]

If you want narrower browser exceptions instead, configure exact hosts:

{
  browser: {
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: false,
      allowedHostnames: ["localhost", "127.0.0.1", "10.0.0.42", "staging.yourlan"]
    }
  }
}

For SearXNG specifically, make sure it’s configured as the web search provider and points at the local URL:

openclaw config set tools.web.search.provider searxng
openclaw config set plugins.entries.searxng.config.webSearch.baseUrl "http://<searxng-host>:8888"

[shadow apex]

openclaw gateway restart

One important catch: web_search with SearXNG and browser navigation have their own trusted-local paths, but the generic web_fetch tool still appears to be strict for arbitrary private URLs in current source. So if a cron literally depends on web_fetch http://staging.local/..., that may still fail even after the browser setting. For staging-site review, route that workflow through the browser tool, or file this as a feature/bug if you need web_fetch to have an operator opt-in too: https://github.com/openclaw/openclaw/issues

Relevant docs:
https://docs.openclaw.ai/tools/browser#ssrf-policy
https://docs.openclaw.ai/gateway/security#browser-ssrf-policy-strict-by-default
https://docs.openclaw.ai/tools/searxng-search
https://docs.openclaw.ai/gateway/configuration-reference

[next lodge]

Doesn't the browser tool rely on a full browser session running on the gateway with screenshotting and computer use? that sounds very processing heavy compared to simple web fetch and I don't think satisfies the efficiency requirement of heavy scraping workflows which I use. it's sounding like I should probably roll back to the previous version. - do you know if there are development plans to allow for disabling this block, or perhaps allowing for a white list of systems (perhaps per agent?) so that users are able to make their own decisions regarding security and agent access control?

[shadow apex]

Yes, your read is right: the browser path is heavier. It means a browser process/control plane and page navigation, and it’s the wrong substitute for high-volume “fetch a lot of internal HTML/API pages and extract text” workflows. I suggested it as a functional workaround for staging review, not as an efficiency-equivalent replacement for web_fetch.

I checked: there is already an open feature request for exactly this:
https://github.com/openclaw/openclaw/issues/39604

It proposes an opt-in config like:

{
  tools: {
    web: {
      fetch: {
        allowPrivateNetwork: true
      }
    }
  }
}

[shadow apex]

Current source/docs still show web_fetch blocking private/internal hosts, and I don’t see a merged PR exposing that knob yet. So the honest answer is: yes, the need is known and filed; I can’t promise maintainer timing.

A host whitelist would be the better shape in my opinion, ideally both:

• broad operator opt-in for trusted LAN/tailnet gateways
• narrower hostnameAllowlist / exact host exceptions, possibly agent/profile-scoped later

For your production workflow, rolling back to 2026.5.7 is a reasonable short-term call if heavy local scraping is core and you understand the security tradeoff. Longer-term, I’d add your use case/details to issue #39604 rather than opening a duplicate: “high-volume internal/staging scraping where browser is too expensive” is useful product signal.

[next lodge]

this has been incredibly helpful. I think for now I'm going to roll back to the previous version and set up a daily cron for my system configuration agent to monitor this feature request and notify me when it has been properly resolved and is included in a release. I really appreciate your helpfulness today -May I ask what model you use?

[shadow apex]

Glad it helped. That rollback + daily monitor is a sensible setup for this specific workflow.

On the model question: I can’t give a reliable “I’m running X” answer here. The runtime can vary by deployment/session, and it’s not a good source of truth for what you should configure. For model choice advice, the best place is #models, plus the docs here:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

For the cron, I’d monitor issue #39604 and the release notes/changelog, then only upgrade once the fix is in a tagged release and you’ve confirmed the config key in docs/source.