#$fetch dns that resolves to ipv6

14 messages · Page 1 of 1 (latest)

cursive ledge
#

Got this composable that has my expressjs backend on the baseURL

export const useApi = () => {
  const config = useRuntimeConfig()
  console.log(config.public.apiBase)
  return $fetch.create({
    baseURL: config.public.apiBase,
    headers: {
      Authorization: `Bearer ${config.apiToken}`
    }
  })
}```

`config.public.apiBase` resolves to an ipv6 and my request returns 404 with a weird formatting, it appends the front end url + the backend url
so it ends up with something like this:
`https://{front end domain}/{apiBase}/`
Which happens because I didn't prepend `https://` in the apiBase value, but if I prepend it also doesn't work so any insight on this is welcome.
terse kindleBOT
#

Hi @cursive ledge. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Your issue is likely related to how you set the value of apiBase in your runtime config. In Nuxt, the public.apiBase is often intended to be a path (e.g., /api) rather than a full URL. If you set it as a full URL (e.g., <https://api.example.com>), you must ensure it is used consistently and does not get concatenated with your frontend domain.

Key points from the documentation:

  • If apiBase is set as a path (e.g., /api), $fetch will resolve it relative to your frontend domain, resulting in requests like <https://frontend.com/api/endpoint.>
  • If you want to use a full backend URL (including protocol and domain), set apiBase to the full URL (e.g., <https://api.example.com>) in your runtime config and ensure you do not accidentally concatenate it with the frontend domain.
  • When using $fetch.create({ baseURL }), the baseURL should be a valid absolute URL if you want to target a different domain or IP (including IPv6). For IPv6, the URL should be formatted as <https://[ipv6-address]:port.>

Example from the docs:

export default defineNuxtConfig({
  runtimeConfig: {
    public: {
      apiBase: process.env.NUXT_PUBLIC_API_BASE || '/api'
    }
  }
})

And in your composable:

const config = useRuntimeConfig()
const api = $fetch.create({
  baseURL: config.public.apiBase
})

If apiBase is a full URL, make sure it includes the protocol (<https://>) and, for IPv6, is wrapped in brackets: <https://[your:ipv6:address]:port.>

Common mistake:
If you set apiBase to a path (like /api) but use it as a full URL, or vice versa, Nuxt will concatenate it with your frontend domain, leading to malformed URLs like <https://frontend.com/https://api.example.com/endpoint> or <https://frontend.com/api/endpoint> when you intended to call the backend directly.

#

Solution:

  • If your backend is on a different domain or IP (including IPv6), set apiBase to the full URL (e.g., <https://[your:ipv6:address]:port>).
  • If your backend is served from the same domain, use a path (e.g., /api).

Reference:
See the official Nuxt docs for runtime config and baseURL usage: useRuntimeConfig, Custom $fetch.

If you still encounter issues, double-check your environment variables and how you set apiBase in your nuxt.config. If you use an IPv6 address, ensure the URL is properly formatted and not being concatenated with your frontend domain unintentionally.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@cursive ledge Kapa.ai is still learning and improving, please let me know how I did by reacting below.

cursive ledge
terse kindleBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

I'm sorry you're running into this issue. Based on the knowledge sources, there isn't explicit documentation in the Nuxt docs about using internal DNS names (like *.railway.internal) with $fetch or runtime config. However, here are some relevant points and limitations from the sources:

  • Nuxt's $fetch will use the baseURL you provide, but if the DNS name (e.g., gohub-web.railway.internal) cannot be resolved from the environment where your Nuxt app is running, you'll get a ERR_NAME_NOT_RESOLVED error. This is a network/DNS issue, not a Nuxt-specific one.
  • The Nuxt runtime config allows you to set a full URL (including protocol and port) for apiBase, and this will be used as-is by $fetch if set correctly useRuntimeConfig docs.
  • If your public domain works but the internal DNS does not, it suggests that the environment where your Nuxt app is running (browser or server) cannot resolve the internal DNS name. This is common if the internal DNS is only available within a private network or specific containers.

Key points from the sources:

  • There is no mention of special handling for internal DNS or private networks in Nuxt's runtime config or $fetch usage.
  • The error you see (ERR_NAME_NOT_RESOLVED) is a DNS/networking issue, not a Nuxt config issue.
#

What you can do:

Summary:
The knowledge sources do not provide a Nuxt-specific solution for internal DNS resolution issues. Your error is likely due to network configuration or DNS resolution in your deployment environment, not Nuxt itself. Double-check your network setup and ensure the Nuxt server can resolve and reach the internal DNS name.

If you need more help, please provide details about your deployment environment and how your services are networked.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@cursive ledge Kapa.ai is still learning and improving, please let me know how I did by reacting below.

cursive ledge
terse kindleBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources, Nuxt’s $fetch should work with any valid URL, including private/internal network addresses, as long as the environment where the SSR server is running can resolve and access that address. There is no Nuxt-specific restriction or special handling for internal/private DNS names in $fetch or runtime config. The documentation and examples show that $fetch simply uses the URL you provide, and if you set a full URL (with protocol and port) in your runtime config, it will be used as-is see docs.

However, the sources also clarify that if you encounter a ERR_NAME_NOT_RESOLVED error, it is due to DNS/network resolution issues in your environment, not a limitation or behavior of Nuxt itself. This is supported by the fact that Nuxt’s SSR server will make the request from its own network context, so if it cannot resolve the internal DNS name, the request will fail see related networking issues.

There is no information in the knowledge sources indicating that Nuxt blocks or rewrites private/internal URLs, nor that $fetch behaves differently for internal addresses. If the same setup works in other projects but not in Nuxt, the only Nuxt-specific caveat is that SSR requests are made from the server context, not the browser, so the server must have access to the internal DNS.

Summary:
The knowledge sources do not indicate any Nuxt-specific reason why $fetch would not work with a private network URL in SSR mode. If DNS resolution and network access are correct, $fetch should work as expected. If it does not, the issue is likely environmental (network/DNS), not Nuxt-related.

#

If you have confirmed network connectivity and DNS resolution from the SSR server, but $fetch still fails, the knowledge sources do not provide further troubleshooting steps specific to Nuxt.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: