Обслуживание статического веб-сайта в nginx, неправильный путь для статических файлов

Я пытаюсь использовать nginx для обслуживания статического веб-сайта, который мне дали. Его структура папок выглядит следующим образом:

static_website/
    index.html
    www.example.com/
    resources.example.com/
    uploads.example.com/

Файл index.html в корне — это файл, сгенерированный httrack, и он просто содержит перенаправление на www.example.com/index.html. Внутри папки www.example.com находятся все файлы html, в двух других папках находятся файлы css, javascript и image.

Вот конфигурация nginx:

server {
    index index.php index.html index.htm;

    server_name example.com;

    location / {
        root /var/www/static_website/www.example.com;
        try_files $uri $uri/ =404;
        index index.html;
    }

}

Я могу перемещаться по страницам, но файлы css, javascript и изображений не загружаются. Путь к одному из css файлов внутри html такой:

href="../resources.example.com/style.css"

Единственный способ, которым мне удалось заставить это работать, - это иметь такой URL-адрес:

example.com/www.example.com/

Таким образом, все пути правильные. Я хотел бы избежать этого и иметь просто example.com. Есть ли способ сделать это?


nginx nginx-config
person Carlo    schedule 13.03.2019    source источник
comment
Попробуйте добавить еще один location, который соответствует всем файлам ресурсов, например: location ~ \.(css|js|jpg|png|svg)$ { root /var/www/static_website; }   -  person Richard Smith    schedule 13.03.2019
comment
спасибо, так и было. Если вы добавите его как ответ вместо комментария, я могу пометить его как принятый   -  person Carlo    schedule 14.03.2019

Ответы (2)


arrow_upward
1
arrow_downward

Похоже, сайт изначально предназначался для работы с уродливыми URL-адресами, такими как //example.com/www.example.com/.

Но URI относительно пути для ресурсов должны нормально работать относительно /, вам просто нужно предоставить блок location, который соответствует /resources.example.com/.

Например:

location / {
    root /var/www/static_website/www.example.com;
    try_files $uri $uri/ =404;
    index index.html;
}
location /resources.example.com/ {
    root /var/www/static_website;
}

Я изначально прокомментировал, что вы должны попробовать это:

location ~ \.(css|js|jpg|png|svg)$ { 
    root /var/www/static_website;
}

Это позволяет достичь той же цели, но Nginx будет обрабатывать расположение префиксов более эффективно, чем расположение регулярных выражений.

person Richard Smith    schedule 14.03.2019

arrow_upward
0
arrow_downward

Я хочу поделиться своим опытом с этой проблемой для других, столкнувшихся с подобными проблемами, поскольку решение не было для меня столь очевидным.

Моя настройка и проблема, в частности, были связаны с настройками cloudlflare, которые я использовал для использования TLS вместо того, чтобы обрабатывать его на исходном сервере для одного из двух моих сайтов. если вы обслуживаете свой сайт из CDN, поддерживающей шифрование, и используете nginx в своем источнике, рассмотрите следующую настройку:

# static1.conf
{ server_name static1.com; root: /var/www/static1/public; listen 80; listen 443; }

# static2.conf - no tls setup in nginx, figured id let cloudflare handle it
{ server_name static2.com; root: /var/www/static2/public; listen 80; }

static1 был настроен в источнике с помощью letsencrypt для обработки соединений tls.

static2 был настроен в источнике без какой-либо конфигурации tls.

слева направо, вот соответствующие облачные режимы TLS, которые позволили мне получить доступ к нужным файлам через nginx

введите здесь описание изображения

Различие между полным и гибким заключается в том, что полный режим позволяет источнику обрабатывать сертификат.

Первоначально у меня был сайт static2, неправильно сконфигурированный как полный, в котором отсутствовала директива listen для 443, из-за чего nginx вместо этого обслуживал static1.

Я понимаю, что первоначальный вопрос не имеет ничего общего с cdn или cloudflare, но это несоответствие схемы/протокола стоило мне нескольких часов, и я надеюсь спасти кого-то еще от подобного горя.

Честно говоря, я удивлен, что nginx не придерживается сопоставления по server_name, и это неявно соответствует схеме в качестве запасного варианта (или, по крайней мере, кажется), даже без указания default_server - и без каких-либо значимых сообщений в журналах для загрузки! Отладка nginx иногда превращается в кошмар.

person lfender6445    schedule 15.12.2020