Hanging on the last step of setup

[russkiimike]

How Shlink is set-up

• Shlink Version: 2.4.2
• PHP Version: 7.4.3
• How do you serve Shlink: Self-hosted swoole
• Database engine used: MySQL

Summary

Been struggling for weeks to setup shlink since I am new to unix. Finally today got to the stage where I am able to get 404 redirects on the base url but whenever I try to create a server on the web client app.shlink.io it fails to connect (Make sure you have internet connection, and the server is properly configured and on-line). SSL labs is all green, I exposed Shlink through a reverse proxy using the ngnix sample in the docs. Any help appreciated thanks!

[codaamok]

Can you share your nginx config?

If you've been playing a bit of hot potato with your DNS records this could also be a factor as to why the public web app (app.shlink.io) might be struggling to connect.

[russkiimike]

Cause I have the vps on digital ocean and the domain register as Godaddy, I pointed gd to the digital ocean nameservers. Whatsmydns is looking fine and ssl labs too. It's at https://xrci.se. P.S sorry about the formating

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://127.0.0.1:8080;
                try_files $uri $uri/ =404;
        }

server {

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.php index.html index.htm index.nginx-debian.html;
    server_name www.xrci.se xrci.se; # managed by Certbot


        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                  proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://localhost:8080;
        proxy_read_timeout 90s;
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}


    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/xrci.se/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/xrci.se/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot




    add_header Strict-Transport-Security "max-age=31536000" always; # managed by Certbot
}
server {
    if ($host = www.xrci.se) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = xrci.se) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 ;
        listen [::]:80 ;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.php index.html index.htm index.nginx-debian.html;
    server_name www.xrci.se xrci.se; # managed by Certbot 
   location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                  proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://localhost:8080;
        proxy_read_timeout 90s;
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}

[acelaya]

I have edited your comment to add some formatting to the nginx config. I hope you don't mind.

First thing I see is that the first and last server blocks are missing the closing brace. I'll assume it's just a copy/paste issue, as nginx would complain, but check that just in case.

The next thing I see is that the base URL properly redirects somewhere, which means the proxy is forwarding the traffic to Shlink.

However, visiting an invalid short URL (like https://xrci.se/ffff) returns an nginx 404 instead of a Shlink one, therefore, it's not forwarding traffic for any subpath, which is what makes the Shlink web client fail.

I think that's because of the try_files instructions you have together with the proxy_... ones. Try removing them.

A good route to test if it's properly configured is this one https://xrci.se/rest/health. When it's correctly configured, you should see something like this https://slnk.to/rest/health

Also, you can find here a basic nginx proxy config that might help https://shlink.io/documentation/serve-with-swoole/#exposing-shlink-through-a-reverse-proxy

It's the one I use for my own Shlink instance.

[russkiimike]

Thank you for the edit. Do you know what? I used that example but when I opened the config file for nginx I didn't want to delete everything so I just added onto it. I have erased everything now and it works !! Thank you so much. Resources wise, how does it scale?

[acelaya]

It should handle high loads reasonably well. There are users with a couple of hundred thousand links, and others supporting millions of visits on their links, with no issues.

It's only a bit slow when trying to load big visits collections from the rest API, but that won't impact visitors. See #780

I have also done some load tests in the past with promissing results, and I plan to to more and publish the results at some point.

In any case, if you expect a lot of concurrent traffic, it's just a matter of throwing more resources to it. Clustering shlink shouldn't be a problem.

[acelaya]

Since the original problem is solved, I'll close the issue. Feel free to open another one if something else comes up.