Backend does not seem to start on a ubuntu headless server

[KittySoldier]

i have a server running a headless version of ubuntu 24.04.
i installed TTS webui onto it using the start_tts_webui.sh and chose nvidia for the 3090 that the server has.
the frontend starts just fine and is reachable from any computer connected to the network, but trying to run any model at all yields the same error:

Submit function encountered an error: Error: There is no endpoint matching that name of fn_index matching that number.
    at /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:23855
    at Client.submit (/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:23986)
    at /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:15704
    at new Promise (<anonymous>)
    at Client.predict (/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:15662)
    at /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/pages/api/gradio/[name].js:1:1860
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async handler (/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/pages/api/gradio/[name].js:1:1565)
Error: There is no endpoint matching that name of fn_index matching that number.
    at /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:23855
    at Client.submit (/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:23986)
    at /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:15704
    at new Promise (<anonymous>)
    at Client.predict (/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/chunks/6327.js:1:15662)
    at /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/pages/api/gradio/[name].js:1:1860
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async handler (/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/react-ui/.next/server/pages/api/gradio/[name].js:1:1565)

i suspect that it is because the backend fails to load. Here is the output of the start script:

/usr/bin/curl
/usr/bin/tar
/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/installer_files/env/bin/bzip2
Checking if the Micromamba/Conda environment is already installed
Micromamba/Conda environment already installed in /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/installer_files/env, skipping installation
/usr/bin/gcc
Unified server started on port 7771
Web console and log viewer available at http://localhost:7771


Starting init app (version: 0.1.0)...


Checking conda installation...
>[async] conda --version
Failed to open browser: Command failed: xdg-open http://localhost:7771
/usr/bin/xdg-open: 882: www-browser: not found
/usr/bin/xdg-open: 882: links2: not found
/usr/bin/xdg-open: 882: elinks: not found
/usr/bin/xdg-open: 882: links: not found
/usr/bin/xdg-open: 882: lynx: not found
/usr/bin/xdg-open: 882: w3m: not found
xdg-open: no method available for opening 'http://localhost:7771'

conda 25.5.1

>[async] conda info --envs
>[async] node --version
>[async] python --version
>[async] pip --version
Pulling updates from tts-webui
>[async] git pull
Python 3.10.11
v22.9.0
pip 25.1.1 from /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/installer_files/env/lib/python3.10/site-packages/pip (python 3.10)
/home/lucy/ai/tts/tts-webui/TTS-WebUI-main/installer_files/env/lib/python3.10/site-packages/conda/base/context.py:211: FutureWarning: Adding 'defaults' to channel list implicitly is deprecated and will be removed in 25.9.

To remove this warning, please choose a default channel explicitly with conda's regular configuration system, e.g. by adding 'defaults' to the list of channels:

  conda config --add channels defaults

For more information see https://docs.conda.io/projects/conda/en/stable/user-guide/configuration/use-condarc.html

  deprecated.topic(

# conda environments:
#
base                 * /home/lucy/ai/tts/tts-webui/TTS-WebUI-main/installer_files/env
                       /home/lucy/miniconda
                       /home/lucy/miniconda/envs/xtts

Already up to date.
Current git version: ec286fe2881aefaf164367d2f6669af25e4cd921

No updates found, skipping...
>[async] pip show torch torchvision torchaudio


Finished init app.

2025-07-21 18:49:46.926 UTC [83933] LOG:  starting PostgreSQL 16.4 on x86_64-conda-linux-gnu, compiled by x86_64-conda-linux-gnu-cc (conda-forge gcc 13.3.0-1) 13.3.0, 64-bit
2025-07-21 18:49:46.926 UTC [83933] LOG:  listening on IPv4 address "127.0.0.1", port 7773
2025-07-21 18:49:46.928 UTC [83933] LOG:  listening on Unix socket "/tmp/.s.PGSQL.7773"
2025-07-21 18:49:46.932 UTC [83942] LOG:  database system was shut down at 2025-07-21 18:48:26 UTC
2025-07-21 18:49:46.935 UTC [83933] LOG:  database system is ready to accept connections

> tts-webui-react@0.4.0 start
> next start

  ▲ Next.js 13.5.6
  - Local:        http://localhost:3000

I am likely doing something wrong, but looking through the docker and manual install instructions, i could find very little that explains my issue ^^*

[C00reNUT]

I get the same error on the ubuntu headless server

[C00reNUT]

I found the solution - actually it is quite simple - instead of using localhost:3000 you need to use 127.0.0.1:7770 which triggers different UI - in there you can easily install the extension for chatterbox.

It is slightly misleading because command line ./start_tts_webui.sh says that the gradio is started at port 127.0.0.1:7773

[rsxdalv]

I found the solution - actually it is quite simple - instead of using localhost:3000 you need to use 127.0.0.1:7770 which triggers different UI - in there you can easily install the extension for chatterbox.

It is slightly misleading because command line ./start_tts_webui.sh says that the gradio is started at port 127.0.0.1:7773

Glad you solved it.

7773 is postgres,
3000 is React
7770 is gradio
7771 is log viewer

At some point I might create a proxy that combines React, Gradio and Log viewer under a single port but it's extra work with little upside.

[rsxdalv]

@KittySoldier I'm not certain what causes this, since the Docker container is also ubuntu and I assume is headless as well. I have also previously installed it on my headless WSL.
I would guess that it is the missing chatterbox extension, however you said that none of the models work, which would indicate that the backend is well and truly offline.
Are you able to access the 7770 gradio interface, a.k.a the "backend"?

[C00reNUT]

I found the solution - actually it is quite simple - instead of using localhost:3000 you need to use 127.0.0.1:7770 which triggers different UI - in there you can easily install the extension for chatterbox.
It is slightly misleading because command line ./start_tts_webui.sh says that the gradio is started at port 127.0.0.1:7773

Glad you solved it.

7773 is postgres, 3000 is React 7770 is gradio 7771 is log viewer

At some point I might create a proxy that combines React, Gradio and Log viewer under a single port but it's extra work with little upside.

@rsxdalv thank you for the additional info and also for keeping this library alive and adding new features and models!

[KittySoldier]

@KittySoldier I'm not certain what causes this, since the Docker container is also ubuntu and I assume is headless as well. I have also previously installed it on my headless WSL. I would guess that it is the missing chatterbox extension, however you said that none of the models work, which would indicate that the backend is well and truly offline. Are you able to access the 7770 gradio interface, a.k.a the "backend"?

Just got home and was able to test it out!
I tested them all. These give me a 'unable to connect' error
https://{internal server ip}:7773
https://{internal server ip}:7770
https://{internal server ip}:7771
i tested this on three browsers and two separate devices. For good measure, i disabled the firewall on the server.

https://{internal server ip}:3000 is accessible on all browsers, both devices, with the firewall on.
other projects like this require me to add something like --listen when i run their start script. Is it possible that i am missing that somewhere?

ill see if i can get ngrix to expose that port to the internal network, maybe then i can access it.
Just to be clear, the server and the devices i use to test the connection are all different machines that share the same private network.

EDIT:
i got somewhere.. i think..
this is my temporary ngrix configuration

server {
    listen 7670;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:7770;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

server {
    listen 7671;
    server_name _;
        location / {
        proxy_pass http://127.0.0.1:7771;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

server {
    listen 7673;
    server_name _;
        location / {
        proxy_pass http://127.0.0.1:7773;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

figured i could test enabling websockets as a test, but both before and after had the same result:

it gets stuck on this loading screen, there is no response in the server log.

going to https://{internal server ip}:7670 gives me the infinite loading screen
https://{internal server ip}:7671 gives me a 502 bad gateway error from ngrix
https://{internal server ip}:7673 gives me a 502 bad gateway error from ngrix, but oddly also puts one line in the log:

2025-07-24 20:47:02.903 UTC [2363561] LOG: invalid length of startup packet

thanks for the help so far ^^

[rsxdalv]

--listen would typically just mean that you set the hostname to 0.0.0.0 which means that it will respond to requests for 127.0.0.1, localhost, 192.168... etc
Could that be the missing piece?

[mharrys]

I think it is just a problem with the bind address rather than it being headless since those machines are accessed from another host. I can access the react page on port 3000, but not Gradio on port 7770 from another host. We can see by looking at the listening ports that 7770 only accept connections originating from same host, where as 3000 can accept connections from a remote host.

127.0.0.1:7770
*:3000

I tested to forward the connection on another port (there are many different ways to forward the connection, here is just one example)

sudo socat TCP-LISTEN:8880,fork TCP:127.0.0.1:7770

and I can now also access Gradio (although on port 8880) from another host and use the models. Does not solve the errors on the react page though, but the models are usable via Gradio. Potentially default to localhost/127.0.0.1 on all ports, but have the option to change to another bind address via ENV or param.

[rsxdalv]

Could you see if the options in config.json can suit your use case? With react I'm not certain if it'll detect the host correctly, but I think it should be able to just call localhost, if gradio remains open to 0.0.0.0

…

On Wed, Sep 3, 2025, 23:17 mharrys ***@***.***> wrote: *mharrys* left a comment (rsxdalv/TTS-WebUI#548) <#548 (comment)> I think it is just a problem with the bind address rather than it being headless since those machines are accessed from another host. I can access the react page on port 3000, but not Gradio on port 7770 from another host. We can see by looking at the listening ports that 7770 only accept connections originating from same host, where as 3000 can accept connections from a remote host. 127.0.0.1:7770 *:3000 I tested to forward the connection on another port (there are many different ways to forward the connection, here is just one example) sudo socat TCP-LISTEN:8880,fork TCP:127.0.0.1:7770 and I can now also access Gradio (although on port 8880) from another host and use the models. Does not solve the errors on the react page though, but the models are usable via Gradio. Potentially default to localhost/ 127.0.0.1 on all ports, but have the option to change to another bind address via ENV or param. — Reply to this email directly, view it on GitHub <#548 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTRXIYDBKSRY7FL323BR5L3Q5EEFAVCNFSM6AAAAACCAVCG56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENJQGY2DANRZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>