Загадочные перенаправления при обслуживании сайта Wordpress на Nginx за обратным прокси-сервером Caddy

Я сам размещаю кучу сервисов, которые размещены на различных виртуальных машинах/контейнерах, и использую сервер Caddy v1 в качестве обратного прокси-сервера для доступа к ним через различные поддомены.

Недавно я запустил пару сайтов Wordpress, которые размещены на отдельной виртуальной машине с сервером Nginx и отдельными конфигурациями с поддержкой сайтов для каждого, но с общим экземпляром Mariadb и уникальными префиксами таблиц WP.

Я начал с размещения одного из этих сайтов на поддомене моего основного домена, назовем его apple.orange.com, и он отлично работал с автоматическими сертификатами LE от Caddy. Я получил для него выделенный домен, скажем, apple.com, и попытался изменить конфигурацию Caddy на:

  1. Прокси apple.com к моей виртуальной машине Nginx.
  2. Перенаправьте адрес apple.orange.com на apple.com.

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

Здесь я начал сталкиваться с проблемами, которых не ожидал. Я начал получать слишком много перенаправлений, когда пытался зайти на apple.com, и обнаружил, что apple.com перенаправляет на apple.orange.com, что было очень странно, а apple.orange.com перенаправляет на apple.com, как ожидалось, создавая петлю.

Я изменил свой Caddyfile на прокси-сервер apple.orange.com на свой nginx vm и добавил конфигурацию сайта для обслуживания одних и тех же файлов на Orange.apple.com и apple.com, чтобы восстановить работоспособность сайта.

С тех пор мне не удалось заставить apple.com прекратить перенаправление на Orange.apple.com.

Я старался:

  1. Перезагрузка обоих серверов.
  2. Удаление любого упоминания об apple.orange.com в моем Caddyfile, но это только сделало apple.com перенаправлением на сайт, которого больше не существует.
  3. Настроил совершенно новый экземпляр Caddy и добавил только apple.com в качестве прокси-сервера к моему nginx vm, но мне пришлось скопировать сертификаты из моего старого экземпляра в новый, потому что я достиг предела скорости LE в течение недели, и это не помогло. изменить ситуацию, и apple.com по-прежнему перенаправлял на apple.orange.com.
  4. Полностью удалил apple.orange.com из конфигурации сайтов nginx, но это просто остановило обслуживание сайта.
  5. Просматривая любые каталоги кеша, которые могут содержать неверную конфигурацию на любом из веб-серверов, но ничего не нашел.

Итак, я здесь, после 3 безумных дней, полностью сбитый с толку тем, что происходит. Был бы признателен за любое понимание того, как обойти отладку этого.

Вот куча соответствующих файлов/конфигураций:

Caddyfile

# a bunch of other subdomains exist in the same file, but I also tried with just this.
apple.com, www.apple.com {
  proxy / 10.0.1.108 {
    transparent
  }
}
apple.orange.com
  proxy / 10.0.1.108 {
    transparent
  }
}

/etc/nginx/sites-enabled/apple.com

server {
    listen 80;
    listen [::]:80;
    root /var/www/html/apple.com;
    index  index.php index.html index.htm;
    server_name apple.com www.apple.com *.apple.com apple.orange.com;

    client_max_body_size 100M;
    autoindex off;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
    }
}

/etc/nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;

    # Compression level (1-9)
    gzip_comp_level     5;

    # Don't compress anything under 256 bytes
    gzip_min_length     256;

    # Compress output of these MIME-types
    gzip_types
        application/atom+xml
        application/javascript
        application/json
        application/rss+xml
        application/vnd.ms-fontobject
        application/x-font-ttf
        application/x-font-opentype
        application/x-font-truetype
        application/x-javascript
        application/x-web-app-manifest+json
        application/xhtml+xml
        application/xml
        font/eot
        font/opentype
        font/otf
        image/svg+xml
        image/x-icon
        image/vnd.microsoft.icon
        text/css
        text/plain
        text/javascript
        text/x-component;

    # Disable gzip for bad browsers
    gzip_disable  "MSIE [1-6]\.(?!.*SV1)";
    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}


#mail {
#   # See sample authentication script at:
#   # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#   # auth_http localhost/auth.php;
#   # pop3_capabilities "TOP" "USER";
#   # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#   server {
#       listen     localhost:110;
#       protocol   pop3;
#       proxy      on;
#   }
# 
#   server {
#       listen     localhost:143;
#       protocol   imap;
#       proxy      on;
#   }
#}

Очевидно, что apple.com не принадлежит мне, как и Orange.com. Дайте мне знать, актуальны ли фактические домены (в случае, если это проблема DNS, в чем я сомневаюсь, потому что запросы поступают на мой IP).

Заранее благодарю за любую помощь!


person KaziJehangir    schedule 06.06.2020    source источник


Ответы (1)


Итак, я узнал, в чем проблема, после случайного поиска в Google при переносе сайта WordPress на новый домен. По-видимому, это не так просто, как просто указать домен на сайт nginx, установка WordPress имеет поле URL-адреса сайта, которое должен знать, где обслуживается сайт.

Таким образом, перенаправления исходили не от Caddy, они исходили не от Nginx, а от фактического сайта WordPress.

person KaziJehangir    schedule 07.06.2020