Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

/_nuxt paths don't work behind Apache reverse proxy

See original GitHub issue

Forwarded from downstream issue:

https://github.com/nuxt/framework/issues/5699 by @HendrikJan

Environment

Nuxt CLI v3.0.0-rc.4 18:38:53 RootDir: /home/haaiee/Projects/nuxt3-problem 18:38:55 Nuxt project info: 18:38:55

Operating System: Linux
Node Version: v16.15.1
Nuxt Version: 3.0.0-rc.4
Package Manager: npm@8.11.0
Builder: vite
User Config: -
Runtime Modules: -
Build Modules: -

Reproduction

Start the server:

Clone this repo: https://github.com/HendrikJan/nuxt3-problem
docker compose up
docker exec -it my-nodejs bash
npm run dev (retry if you get EADDRINUSE error)
See that the page http://localhost:7777/ does not load
See that http://localhost:7777/api/hello does load correctly so the proxy seems to work fine

See the problem:

In Chrome browser go to http://localhost:7777/ and see error in console: Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec
In Chrome browser in network tab, see that all /_nuxt routes return this html:

<!DOCTYPE html>
<html >

<head >
  
</head>

<body >
  <div id="__nuxt"></div><script>window.__NUXT__={serverRendered:false,config:{public:{},app:{baseURL:"\u002F",buildAssetsDir:"\u002F_nuxt\u002F",cdnURL:""}}}</script><script type="module" src="/_nuxt/@vite/client"></script><script type="module" src="/_nuxt/entry.mjs"></script>
</body>

</html>

Add ssr: true to nuxt.config.ts and see that the page does load (but still with errors in console)

Describe the bug

Nuxt3 does not work behind an Apache proxy. With ssr: true we get an error in the console. With ssr: false the page stays blank.

Additional context

Server-generated content (generated with ssr: true or served from /server/api) works correctly behind proxy, but client side content give errors.

The proxy settings are very simple (see /docker/apache/extra/httpd-vhosts.conf):

<VirtualHost _default_:80>
	ServerName localhost
	ServerAlias localhost

  <Location ~ ".*">
    # .* is a wildcard for any location
    ProxyPreserveHost On
    ProxyPass http://my-nodejs:3000/
    ProxyPassReverse http://my-nodejs:3000/
  </Location>
	
  ErrorLog logs/proxy.log
  CustomLog logs/proxy-access.log combined
</VirtualHost>

The resulting port 7777 comes from the docker-compose.yml setting:

    ports:
      - '7777:80'

Logs

No response

Issue Analytics

State:
Created a year ago
Comments:6 (3 by maintainers)

Top GitHub Comments

1reaction

gerb-stercommented, Jul 7, 2022

A.f.i.k. is the problem to be found in the Apache configuration; try this one:

<VirtualHost _default_:80>
  ServerName localhost
  ServerAlias localhost

  ProxyPreserveHost On

  <Location />
    # .* is a wildcard for any location

    ProxyPass http://xnodejs:3000/
    ProxyPassReverse http://xnodejs:3000/

    Order allow,deny
    Allow from all
  </Location>
	
  ErrorLog logs/proxy.log
  CustomLog logs/proxy-access.log combined
</VirtualHost>

0reactions

sapphi-redcommented, Jul 12, 2022

This seems to be caused by the ProxyPass,ProxyPassReverse config. ProxyPreserveHost somehow fixes this, but I think that is just a sideeffect and not the root cause.

<VirtualHost _default_:80>
	ServerName localhost
	ServerAlias localhost

  <Location ~ ".*">
    # .* is a wildcard for any location
    ProxyPreserveHost On
    # ProxyPass http://xnodejs:3000/
    # ProxyPassReverse http://xnodejs:3000/
    ProxyPass http://xnodejs:3000
    ProxyPassReverse http://xnodejs:3000
  </Location>
	
  ErrorLog logs/proxy.log
  CustomLog logs/proxy-access.log combined
</VirtualHost>

When ProxyPass is set to http://xnodejs:3000/, the request came to //@vite/client. After changing that to http://xnodejs:3000 (removed the last slash), it worked.

Closing as this is not a bug in Vite.

FYI I added a brief description about how to debug this to vite-setup-catalogue. 👍