Subdomain mess-up with two local IPs

So it did require a2ensite.
I wonder why you didn’t try that sooner…

1 Like

@rg305 Because the original domain had worked until I messed with the subdomain on Box 2. I didn’t suspect that (re-)enabling it would be needed, but it was logical that the subdomain would have to be enabled. I found out when I mulled over the result from apache2ctl -S.

1 Like

it’s because you had multiple virtualhosts on port 443 with different ssl activation statuses: SSLEngine on was missing in the one that prevailed.

1 Like

So then… (file) “Order Matters”.
[I often tell my kids this - like: “Socks go in before shoes (not after)!”]

Or an even better takeaway: SSLEngine on should probably be initiated in the main config.

And, of course there is also, placing a file in the sites-available folder usually does nearly nothing - without also enabling it (via: a2ensite <site>)

1 Like

No, because you don’t want to break port 80.

I don’t know how apache solves this kind of conflicts – is it the first? is there a default? – but it’s safe to say that it should be in every port 443 vhost (or in none, but that doesn’t make sense)

1 Like

OK so then:
Apply SSLEngine on within ALL TLS sections.
[that seems to work in my test Apache system]


yes, and that’s not a problem if you use certbot.

because you can create a section on port 80 only, with no SSLEngine directive and so, and certbot will create a new TLS section with the right configs.


Well, we are beyond the SSL problems, and your help has solved the most serious problems, but I am not totally where I want to be. I cannot ask you to help me, as we are outside the scope of this forum. However, I would be grateful for any hints as to why my little internet radio doesn’t work. Thank you.

1 Like

because the url it’s configured to load is
instead of the proper public one.

There should be configuration options in your application.


To add some clarity to this…
The initial URL seems useable:


But the redirection to, or use of, an RFC 1918 IP address ( makes it unreachable.

I do see that now the site is returning 503 Service Unavailable; perhaps that means you are making changes and hopefully making progress.

Best of luck :slight_smile:

Edit: now I see this again:

curl -Iki
HTTP/2 307
date: Sat, 21 Mar 2020 21:57:52 GMT
server: nginx
strict-transport-security: max-age=15768000; includeSubDomains; preload
content-type: text/html; charset=UTF-8
x-xss-protection: 1
x-content-type-options: nosniff
x-robots-tag: none
referrer-policy: no-referrer-when-downgrade
1 Like

The problem is within the nginx configuration.

It seems to be redirecting (307 temporary) instead of proxying.

I assume the 307 is returned by the app, not by nginx.

This was indeed an issue with the app. It has a “prefer browser URL” checkbox that has to be disabled. The radio station should now basically work. The intent is to broadcast my own concerts and readings for people who are house-bound and quarantined.


I can hear it fine. It works. :smiley:

There’s a little problem, the actual mp3 file is served over unencrypted http, you get a mixed content immagine warning. You should tell the app to use browser protocol/schema too (or to use relative urls)


Thanks :slight_smile: The mixed content warning is not unusual with Icecast streams, because it doesn’t have support for SSL due to licensing issues (sic) unless you build it from source yourself. That’s why, I am told. This is not ideal for modern browsers, AFAIK Chrome doesn’t allow it at all.


This is why you should get apache on box1 to handle this.

what’s its virtualhost config for the webradio right now? (it’s redirecting, that’s good)

1 Like

Hi @eivind


are your addresses, that’s your mixed content.

1 Like

I looked around, the setting you should be looking for is “use web proxy” or something like that:

(and check the mount point url)

1 Like

There is a web proxy setting, and it is already switched on. The documentation says that this routes all radio through ports 80 and 443 instead of the standard Icecast port 8000.

1 Like

we need to make azuracast believe it’s https even if it’s serving unencrypted http.

you can try adding to the apache proxy config something like:

RequestHeader set X-Forwarded-Proto %{REQUEST_SCHEME}

and hope it works.

1 Like