Как настроить обратный прокси на внешний сервер в IIS

Что касается вопроса и комментариев, перенаправление на внешний URL-адрес возможно в IIS как показано здесь.

<system.webServer>
  <rewrite>
    <rules>
      <rule name="External Redirect" stopProcessing="true">
        <match url="^VirtualDirectory" negate="true" />
        <conditions>
          <add input="{HTTP_HOST}" ignoreCase="true" negate="true" pattern="hostname"/>
          <!-- add this input condotion to make this redirect url not work with http://hostname/VirtualDirectory -->
        </conditions>
        <action type="Redirect" url="{your url}" redirectType="Found" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

Кроме того, с помощью NGIX возможно простое перенаправление и адресовано, например, в этом ответе.

server {
    listen 80;
    server_name     example.com;
    return          301 http://www.example.com$request_uri;

server {
    listen 80;
    server_name     www.example.com;
    [...]

и в этом ответе

server {
  listen 80;
  server_name localhost;
  merge_slashes off;

  location /rdr {
    location /rdr/http:// {
      rewrite ^/rdr/(.*)$ $1 permanent;
    }
    rewrite ^/rdr/(.*)$ http://$1 permanent;
  }
}

Тем не менее, вы хотите не видеть содержимое этой страницы, а сохранить эти данные в любом месте и затем снова выполнить перенаправление. Откуда тогда эти данные будут поступать в IFRAME?

Вместо этого redirect > save data > redirectЯ бы посоветовал сделать это отдельно. В частности, вы получите данные из https://trees.com/ficus/macrophylla и сохраните его в папке https://figs.wild.com.au/trees/ficus/macrophylla и используйте то, что вы хотите из этого файла для IFRAME.

Чтобы получить содержимое файла в папке https://trees.com (без JS и CSS из других файлов) и сохранить его в html-файле, вы бы сделали что-то вроде

from urllib.request import urlopen
html = urlopen("http://trees.com").read().decode('utf-8')
#print(html)
with open("test.html", "w") as file:
    file.write(html)

Это сохранит содержимое в HTML-файл с именем test, который находится в том же месте, что и этот сценарий.

(Если также требуются CSS и JS, проверьте этот ТАК вопрос).

Если вы не хотите проходить через эту суету, есть такие инструменты, как HTTrack которые позволяют загружать целые веб-сайты. Таким образом, вам не нужно будет знать мапсайт, чтобы затем перебирать возможные варианты.

Я вижу удобство того, что вы хотите. Мы продолжим расследование и сообщим вам, если обнаружите, что супер-автоматизированный способ сделать это, но поможет узнать, «Откуда будут поступать эти данные для загрузки в IFRAME?».

Если я пойду в http://www.trees.com/ficus/macrophylla используя браузер, то получите

Если я пойду в http://www.trees.com/ также получит следующие

Использование SSL-запроса к tree.com

Нажав "Щелкните здесь, чтобы игнорировать несоответствие ...", вы получите

В конфигурации

мы видим, что поддерживаются TLS 1.0, 1.1, 1.2 и 1.3. Еще зеленый цвет для TLS 1.2 и 1.3.

Мы можем настроить PowerShell для использования TLS 1.3

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls13

И подтвердите, что он будет его использовать

[Net.ServicePointManager]::SecurityProtocol

В PowerShell (как администратор), если вы используете Invoke-WebRequest

Invoke-WebRequest -Uri trees.com/ficus/macrophylla

тогда получит

и если использовать

Invoke-WebRequest -Uri trees.com

тогда получит

Все идет нормально. Но если мы хотим протестировать его на CORS из https://figs.wild.com.au,

(Invoke-WebRequest -Uri 'http://trees.com' -Headers @{ "Origin" = "https://figs.wild.com.au" }).Headers

мы получили

Key                           Value
---                           -----
Transfer-Encoding             chunked
X-Adblock-Key                 MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAL/3/SrV7P8AsTHMFSpPmYbyv2PkACHwmG9Z+1IFZq3vA54IN7pQcGnhgNo+8SN9r/KtUWCb9OPqTfWM1N4w/EUCAwEAAQ==_FamzgofQ7ugTniHINrZ7yp35i/Nqkt7q/gZsgPGyvhOwIQhj04Bd9+/nir6OLAFDPB56kU4m0GgS7SvEoFqRbQ==
Access-Control-Allow-Origin   *
Access-Control-Allow-Methods  *
Access-Control-Request-Method *
Access-Control-Allow-Headers  *
Access-Control-Max-Age        86400
X-UA-Compatible               IE=Edge,chrome=1
X-Request-Id                  556905ec3cb435a1168cc1b28d70875f
X-Runtime                     0.048014
X-Rack-Cache                  miss
Cache-Control                 max-age=0, private, must-revalidate
Content-Type                  text/html; charset=utf-8
Date                          Mon, 20 Jul 2020 09:40:37 GMT
ETag                          "8e51e434b70033ee6a90cb7397af53f9"
Set-Cookie                    _digiadmin2_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFVEkiJTNmOWRlMDA5NjRiZWZlMzgyZTRmN2NlOWIzZmQxZjIzBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMVFOckhMdElRMWc1cGZBcGl5OGQ1WkVNeXo3elpobWRwc2QyR0djTFlNUEE9BjsARg%3D%3D--e55261be794bb9f95ee407c73a3e2b315ef...
Server                        nginx/1.10.1

Заметь Access-Control-Allow-Origin имеет ценность звездочка (*) что означает, что разрешен любой домен. Затем, если мы воспользуемся следующей командой

Invoke-WebRequest -Uri 'http://trees.com' -Headers @{ "Origin" = "https://figs.wild.com.au" }

получим следующий результат

Другими словами, он разрешает запрос из разных источников, а не блокирует, как вы упоминаете в вопросе. Может быть, вы также даете фиктивные URL-адреса только для объяснения.