Hey, you’re not alone. I can confirm that when upgrading Angular 8 to 10 I could face exactly same issue once trying to run with the new server-ssr schematic.

This is indeed a very annoying bug: It makes local development with SSR almost impossible since one has to rebuild the full prod bundle on each change.

Have the same issue. I tried to investigate the source code of the @nguniversal/builders package and I discovered that if I increase the number of attempts here: https://github.com/angular/universal/blob/3ca407beb3a4f5d96f140cf47c259f80b62f3ae5/modules/builders/src/ssr-dev-server/utils.ts#L79 then it works well.

It seems like my app doesn’t boot fast enought to be connected to the dev-ssr process before the number of attempts are exceeded.

Thanks for reporting this issue. However, you didn’t provide sufficient information for us to understand and reproduce the problem. Please check out our submission guidelines to understand why we can’t act on issues that are lacking important information.

If the problem persists, please file a new issue and ensure you provide all of the required information when filling out the issue template.

I’am seeing this error with the dev:ssr NPM script.

I tried to change attemts to 100 in https://github.com/angular/universal/blob/3ca407beb3a4f5d96f140cf47c259f80b62f3ae5/modules/builders/src/ssr-dev-server/utils.ts#L79

The server lasted much longer, but still died in the end.

I believe the above code waits for the server to start on a randomized port. Hence the ECONNREFUSED 127.0.0.1:53233

This solved the dev-server crashing for me:

const port = process.env.PORT || 4000 // <--- process.env.PORT holds the randomized port. Use 4000 for production builds.
expressApp.listen(port, () => {
  console.log(`Node Express server listening on http://localhost:${port}`);
})

I believe we need to check process.env.PORT, and start express on the randomized port for the waiting logic to work. Then there probably is some proxy-magic that forwards the random port to 4200?

Edit: ^ This is the same problem as @rsouthgate describes

I understand why this was closed and that resources are limited, but for cases like this that are experienced by a significant number of users who aren’t able to identify the source of the issue, can the @nguniversal team consider handling these more like customer service requests than backlog items, and help share the repro burden? Maybe have an intern look at it? Even if it’s not bug-related, it’s clearly still a common “gotcha”; there’s value in finding and documenting the cause and any workarounds.

I get this same error trying to enable SSR with a .NET 6/Angular 14 app, but only when architect:server:options:main is set to src\main.server.ts. When I set it to server.ts, I get a “the module at …\main.js does not export a default function” error via a NodeInvocationException.

The Angular Universal downloadable sample shows it set to server.ts, but this super-helpful article points it to src\main.server.ts. Which should it be?

@alan-agius4 & Angular team, with Microsoft obsoleting their SpaServices and NodeServices three years ago now, can the community implore you guys again to reach out to Microsoft and create a doc/repo of unified guidance for developing and deploying .NET/Angular projects with Angular Universal SSR? We’re working with sticks and rocks from kind-hearted community members and a dozen dead-end StackOverflow threads.

I tried running yarn serve:ssr instead which also also failed but it printed some useful errors in my console.

In my case it was caused by trying to access the window. I added a couple of if statements and now it works.

I just tried installing angular universal in my angular 13 app. When I run yarn dev:ssr, after it says “Compiled succesfully” it seems like it prints out the entire dist/server/main.js in red, and at the bottom it just says:

A server error has occurred.
node exited with 1 code.
connect ECONNREFUSED 127.0.0.1:57222

How am I supposed to debug this?

Have the same issue. I tried to investigate the source code of the @nguniversal/builders package and I discovered that if I increase the number of attempts here:

https://github.com/angular/universal/blob/3ca407beb3a4f5d96f140cf47c259f80b62f3ae5/modules/builders/src/ssr-dev-server/utils.ts#L79 then it works well.

It seems like my app doesn’t boot fast enought to be connected to the dev-ssr process before the number of attempts are exceeded.

@MarkPieszak Thanks for the suggestion. Did you actually edit the file in the node_modules folder ? That doesn’t sound like a viable solution 😕

Had the similar problem as @rsouthgate. Changing the port to 443 (with ssl keys provided) depending on the environment (for local one). Wasn’t able to debug what’s happening.

Stumbled across this and discovered for me it was that i’d changed the process.env.PORT in server.ts run() to process.env.WEBSITES_PORT (Azure App Services passes that env var through by default). So it would seem that the dev server passes the port to the child process via the hard coded PORT env var invisibly.