WebUI Connection Issue with FlyingFish Stack via Docker Compose

[stillnocake]

Description

While attempting to use FlyingFish as a replacement for npm (due to its lack of SSH proxy support), I encountered an issue when connecting to the WebUI. After setting up a new FlyingFish stack using the provided Docker Compose file and environment file, the attempt to connect to the WebUI resulted in an empty response.

Reproduction Steps

Set up a new FlyingFish stack using the Docker Compose file and environment file. Attempt to connect to the WebUI on port 3000.

Expected Behavior

Successful connection to the FlyingFish WebUI with proper response and interface display.

Actual Behavior

Received an empty response when trying to connect to the WebUI. The Docker logs indicated an error: flyingfish_service could not connect to port 10443.

Upon inspecting the flyingfish_container using netstat -tulnp, I found the following details regarding port 10443:

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.11:38883 0.0.0.0: LISTEN -
tcp 0 0 127.0.0.1:20000 0.0.0.0: LISTEN 18/nginx: master pr tcp 0 0 0.0.0.0:10080 0.0.0.0: LISTEN 18/nginx: master pr tcp 0 0 0.0.0.0:53 0.0.0.0: LISTEN 18/nginx: master pr tcp 0 0 0.0.0.0:80 0.0.0.0: LISTEN 18/nginx: master pr tcp 0 0 0.0.0.0:443 0.0.0.0: LISTEN 18/nginx: master pr tcp 0 0 127.0.0.1:10081 0.0.0.0: LISTEN 18/nginx: master pr tcp6 0 0 :::5333 ::: LISTEN 1/node
tcp6 0 0 :::3000 ::: LISTEN 1/node
udp 0 0 0.0.0.0:42042 0.0.0.0: 1/node
udp 0 0 0.0.0.0:53 0.0.0.0: 18/nginx: master pr udp 0 0 127.0.0.1:514 0.0.0.0: 1/node
udp 0 0 0.0.0.0:34903 0.0.0.0: 1/node
udp 0 0 0.0.0.0:35595 0.0.0.0: 1/node
udp 0 0 0.0.0.0:53479 0.0.0.0: 1/node
udp 0 0 0.0.0.0:5333 0.0.0.0: 1/node
udp 0 0 127.0.0.11:38545 0.0.0.0:* -

Also, here are the logs from the flyingfish_service container:

flyingfish_service | {"level":"silly","message":"NginxService::_startSysLog::SysLogServer::setOnMessage: <190>Jan 13 23:18:53 100af8a12aca nginx: {\"source\":\"nginx\",\"source_type\":\"stream\",\"logging\":\"access\",\"ff_stream_id\":2,\"time\":\"2024-01-13T23:18:53+00:00\",\"msec\":\"1705187933.698\",\"host\":\"5.188.210.227\",\"protocol\":\"TCP\",\"status\":\"502\",\"bytes_sent\":\"0\",\"bytes_received\":\"0\",\"session_time\":\"1.089\",\"upstream_addr\":\"127.0.0.1:10443\",\"upstream_bytes_sent\":\"0\",\"upstream_bytes_received\":\"0\",\"upstream_connect_time\":\"-\"}"}

Any idea what could cause this ?

Thank you for your awesome project !

[stefanwerfling]

Hello @stillnocake, that sounds mysterious. Port 10443 is the internal port in the Docker network. The port 443 listing on the host (outside) records the connection as a “stream” and is directed to the internal port “10443” after operation.

Please check first in the web interface (https://flying-fish.gitbook.io/flyingfish/index/configurations/listen) whether you see an entry with 10443 in "Lists" (maybe you can take a screenshot for me)?

Please remember to replace sensitive data with e.g. "example.com" domain or in the screenshot.

I'll give you the settings later on how you can look into nginx.conf. (I'm going to sleep first).

See you later :)

[stillnocake]

Hello again, the issue here is that it would look like I cannot reach any flyingfish webinterface from anywhere. I have tried to follow the steps provided to setup the solution, but the webserver sends an empty response even from the inside: (the screenshot has been taken from 'docker exec -it flyingfish_service /bin/bash'

Also, I get the same empty message from browsers when trying to reach the page at IP_ADDRESS:3000

The only error message I get from Docker logs is this one:

thank you for your reply !

[stefanwerfling]

Hello @stillnocake, I see you are calling it as http on port 3000. There is a generated certificate for the HTTP protocol on port 3000. So you have to call it with https://:3000/. Important "https". Then the interface should be visible (https://flying-fish.gitbook.io/flyingfish/index/installation/quick-setup)

I'll see if there's a way to store a URL redirect to https on the express, but I don't think so, since only one protocol per port can list http/https (even synology interface has 2 ports for this)

Let me know if it works. :)

[stillnocake]

Oh wow it works thank you :D ! I'll now read on how to make it accept the certificate as it appears as invalid :O

[stefanwerfling]

This is okay for the web interface as it can only be accessed internally. It should never be accessible from outside. It is a self-signed certificate. You can now create domains, routes and valid certificates in the web interface.

:)

[stefanwerfling]

Hello @stillnocake I have now found a way so that this problem (which you had) does not occur again. It will be included in the next version.

https://stackoverflow.com/questions/22453782/nodejs-http-and-https-over-same-port/77819123#77819123