fix(stacks): same-origin RPC proxy so VPN/DNS/CORS can't break reads - #133
Open
BreadrichEngels wants to merge 1 commit into
Open
fix(stacks): same-origin RPC proxy so VPN/DNS/CORS can't break reads#133BreadrichEngels wants to merge 1 commit into
BreadrichEngels wants to merge 1 commit into
Conversation
✅ Deploy Preview for app-stacks ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Olaleye-Blessing
force-pushed
the
fix/rpc-proxy-cors-vpn
branch
from
July 1, 2026 20:34
ca16fa9 to
481c831
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
daopunk hit a CORS / access-control failure that only happened on a VPN (works with VPN off). CORS is enforced by the upstream server, so a VPN shouldn't normally trip it — the likely cause is the VPN's DNS/egress blocking or rerouting the public RPC endpoint, which the browser surfaces as a CORS/load failure.
Fix
Route the primary chain's reads through a first-party
/api/rpcproxy. The browser only ever talks to the app's own origin (which already loaded fine), and the server forwards the JSON-RPC to the upstream — so a client-side DNS/CORS/ad-block filter can't break reads. Bonus: the upstream RPC URL stays off the client.src/app/api/rpc/route.ts— same-origin JSON-RPC proxy (gnosis + sepolia; override upstreams viaGNOSIS_RPC_URL/SEPOLIA_RPC_URL).web3.tsx— the gnosis transport uses the proxy only whenNEXT_PUBLIC_APP_URLis set (absolute base so SSR prefetch works too); otherwise it's a plainhttp()— no behavior change if unconfigured.Only affects reads/simulation (the wagmi transport). Tx submission still goes through Privy/the connector, untouched.
I inferred the public RPC as the blocked endpoint but couldn't see the exact domain in daopunk's screenshot. @daopunk — what's the exact URL in the CORS error? If it's Supabase, WalletConnect, or something else, I'll extend the same-origin approach to that endpoint. To activate this: set
NEXT_PUBLIC_APP_URL=https://stacks.bread.coop(and optionally privateGNOSIS_RPC_URL) in the deploy env.Test plan
NEXT_PUBLIC_APP_URLset, reads flow through/api/rpc(Network tab shows same-origin RPC calls); app works on a VPN.NEXT_PUBLIC_APP_URL→ behaves exactly as before.🤖 Generated with Claude Code