23 days ago
I need help troubleshooting a fetch request from middleware. It fetches internal API endpoint with following URL:${env.BASE_URL}/api/auth/post
The BASE_URL is set in variables like this: [http://${{RAILWAY_PRIVATE_DOMAIN}}:8080](http://${{RAILWAY_PRIVATE_DOMAIN}}:8080)
Everything works in development (as always) but fails when deployed
Fetch returns no error message. Replacing fetch with axios throws AxiosError: Network Error
Project ID: 09e13079-6ea3-4d61-a28a-03ee0221115e
15 Replies
23 days ago
The BASE_URL should be set to http://${{RAILWAY_PRIVATE_DOMAIN}}:8080
If the request is made on the server couldn't you just simply use localhost:8080 ?
If it's being called from the client then you need to prefix your env with NEXT_PUBLIC_ so it becomes NEXT_PUBLIC_BASE_URL and set it to use public domain instead
23 days ago
Yes, request are made at server. Setting BASE_URL to http://localhost:8080` does not help, same issue. Seems that problem is somewhere else than in URL it self.
23 days ago
Nextjs by default listens on port 3000. have you changed the default port to 8080 ?
23 days ago
Railway defaults PORT variable to 8080
23 days ago
Doesn't matter what railway defaults to. You need to change that to what your application listens to
23 days ago
Application listens to 8080
23 days ago
Is this server side or client side? If this is client side you need the public URL
23 days ago
Server side, as already stated...
cybermb
Application listens to 8080
23 days ago
If you have public url attached to your service try visiting https://public_domain/api/auth/post from postman or anything
Does it respond back ?
For public url you do not need to specify port, also make sure you have set the port for your public domain by going into settings.
23 days ago
Yes, api works as intended when accessing through public url. However, I would like to avoid using public domain as solution to not increase ingress/egress costs
23 days ago
I understand. Can you post the exact error you face when making the fetch request inside your middleware ?
23 days ago
Can you try 0.0.0.0:8080/whatever?
23 days ago
Error: fetch failed
at context.fetch (/app/node_modules/next/dist/server/web/sandbox/context.js:322:60)
at r7 (/app/.next/server/src/middleware.js:13:98975)
at r5 (/app/.next/server/src/middleware.js:13:98662)
at handler (/app/.next/server/src/middleware.js:13:99679)
at AsyncLocalStorage.run (node:async_hooks:346:14)
at /app/.next/server/src/middleware.js:13:34520
at AsyncLocalStorage.run (node:async_hooks:346:14)
at /app/.next/server/src/middleware.js:13:34507
at /app/.next/server/src/middleware.js:13:22152
at a.with (/app/.next/server/src/middleware.js:13:123877) {
}The error is not very helpful.
Tried with http://0.0.0.0:8080, same issue
I've done a couple of tests:
you can probably use
process.env.HOSTNAMEoryou can set an env
HOSTNAMEwith0.0.0.0and then use0.0.0.0:8080/whatever
more info here:
https://docs.railway.com/reference/errors/application-failed-to-respond#node--next
I've tried the second and before adding the new env, on start the host was a random string:
- Local: http://f1gof880e512:8080
- Network: http://f1gof880e512:8080after adding the env I've got:
- Local: http://localhost:8080
- Network: http://0.0.0.0:8080connecting via ssh (before the change) I was able to do a wget using the random string and getting a response, trying wget 0.0.0.0:8080 or localhost or 127.0.0.0 the response was an error, after adding the env I was able to do a wget using 0.0.0.0:8080…so in theory it should work…railway suggest to use 0.0.0.0 as host, but I let someone from the team confirm
23 days ago
What is BASE_URL set to during development and currently on railway ?
"you can probably use process.env.HOSTNAME"
Well that is a good suggestion. I changed url constructor and it seems to work: [http://${process.env.HOSTNAME](http://${process.env.HOSTNAME) || "[localhost](localhost)"}:${process.env.PORT || "3000"}
Now question is: does railway interpreter this as internal url or does it count towards egress costs?
I'd be surprised, but I'll let someone from railway to reply on this
23 days ago
This seems to be the internal URL. If you want to use the API internally only, try removing the PUBLIC DOMAIN for that service (if that exists), so that the API can only be consumed via Railway's internal services (just to be sure)
in theory it shouldn't be any egress cost, this is just sending request to itself, but I have a question for you….why your middleware is sending a request to an endpoint in the app? to me it doesn't make a lot of sense, if it's the same app why not running the code you have in the route directly in the middleware?
That is a great question.
The problem comes when you try to access database from middleware. Some database adapters are not designed to be used in edge (browser) runtime.
To work around this problem I have created a separate HTTP API endpoint that middleware could use. Fetch used in server requires an absolute URL.
I'm new to railway, so I might be wrong, but as far as I understood railway deploy a simple node container, I don't think is deploying in edge like vercel…so in theory you can connect from the middleware without any problem
Connecting to database from middleware is NextJS problem. It runs in edge runtime. Until nextjs releases next major version which will support node runtime, this is the solution.
ok, I've had a read to the middleware in nextjs and understood what you mean, thanks!
I'm still a bit confused but it's fine, I didn't move to nextjs app as I don't like it 😂 btw it seems middleware can run on node
https://vercel.com/changelog/middleware-now-supports-node-js
https://nextjs.org/blog/next-15-4
Node.js Middleware (stable)
in any case, is the fetching issue fixed right?
To enable edge runtime you have to use next@canary which should not be used in production.
Anyways, the url problem is solved, yes
Status changed to Solved parmstar • 22 days ago