事情的起因是为了部署 Rsshub 服务为自己的 folo 提供小红书的全文解析，而 folo 是不支持本地/ipv6 的 rsshub ，因此需要将对应设置好小红书 cookie 的 rsshub 服务部署到 ipv4 的公网环境之下，权衡之下采取了该方式进行。

以下简单介绍一下自己的尝试过程：

• 首先尝试利用 vercel 部署：由于部署 rsshub 到 vercel 的方式目前还没修复，如果使用 legacy 分支部署 ，也无法支持小红书的全文获取的需求，对应的环境变量可以直接在 github rsshub 仓库的根目录直接添加 .env 文件即可。
• 其余的部署方式部分是需要收费的，或者说注册起来比较麻烦就没有再去尝试；

本地尝试全文获取主要感谢以下作者的探索和分享，这里不再重复分享，通过添加 Cookie 的方式获取了小红书的 全文 Rss 源：

• 顾佳凯的网络日志 | 小红书RSS的解决方案

但是由于小红书反扒严重，因此使用该方案还是要小心被封或者稳定性等问题，故而暂时没有将该 rsshub 源公开出来。

rsshub 的其余部署细节和配置可以参考：RSSHub 官网的文档，这里不在赘述，

转换 ipv6 服务到 ipv4 环境

我们也知道获取公网的 ipv6 地址是比较容易的，通常普通家庭或者宽带都不会有公网的 ipv4 ，在此情况下 ipv6 的访问支持也并没有十分普及，在一些公共网络环境或者一些公司网络中，很多部署在 ipv6 环境下的网页实际上是没法被访问到的，而通过流量访问，还是有其局限性（流量收费限制）；

因此这里就尝试通过免费的 CloudFlare 的 CDN 服务来将 ipv6 服务代理到 ipv4 环境中，以下是一些相关的资料：

• Cloudflare让IPV6不在鸡肋 | 天增的博客
• 利用cloudflare让ipv4与ipv6互通_NAS存储_什么值得买
• 使用Cloudflare代理为纯IPv6站点添加IPv4访问 - 哔哩哔哩

转换腾讯云解析到 Cloudflare

使用 CF 的 CDN 的方式的先决条件是已经有了自己的域名，同时已经通过/可以通过公网 ipv6 发布自己的服务

Cloudflare 官网： https://dash.cloudflare.com/

主要参考开启 Cloudflare CDN 代理，实现 IPv4 to IPv6 转换_ipv4转发ipv6-CSDN博客 一文，在已经基于 ipv6 部署了服务的情况下，参考该博主的文章将域名的 DNS 解析服务转换到 CF 即可，但是后续可能会遇到访问服务的时候反复重定向的问题，这里可以参考[TroubleShooting]( ### CloudFlare 网站【重定向次数过多】) 部分的解决方案；

P.S. 备注

• 后续还是可以在腾讯云的控制台对子域名申请免费证书，对应的解析在 CF 中进行即可，
• 后续对应子域名的添加可以借助 DDNS-GO 直接更新到 CF 中即可
• CF 对于服务的端口是有要求的，笔者本地是通过 Nginx 进行反向代理各项服务的，因此只需要处理好域名的对应关系即可。
• 通过这种方式，可以使用一个备用域名来将自己的一些服务部署到 ipv4 上。

Troubleshooting 一些问题解决

为 CloudFlare 配置 DDNS-Go 动态更新 ipv6 地址

这里 DDNS-Go 的配置没有什么特别的，主要就是要获取 CloudFlare 的密钥，填入对应的配置中即可，具体的密钥获取位置如下：

首先进入 Profile 页面：

选择 API Tokens 中创建一个新的 Token

选择 Edit zone DNS 模板后设置自己要操作的域名如下，最后点击确定即可获取需要的 Token

DDNS-Go 的话只需要新增一个 Cloudflare 的配置，填入对应的 token 后，在 Ipv6 的部分添加你要跟踪的子域名即可，如果域名不存在 Cloudflare 中，其会自动完成对应记录的添加：

Ref: 3、使用DDNS-GO配置DDNS，通过cloudflare api修改指定域名对应的动态ip - 知乎

CloudFlare 网站【重定向次数过多】

通常都是由于 SSL/TLS 的设置冲突导致的，这里只需要去 CloudFlare 管理面板的 SSL/TLS 菜单中将安全策略改为 Full（Strict）即可解决。

具体操作如下图：

ref：使用 CloudFlare 导致网站「重定向的次数过多」解决方案_wordpess 使用 cloudfare 重定向次数-CSDN博客

Fi

this article purpose is to build an authority page for stable diffusion webui using nginx & python/js. Which can publish my personal stable diffusion server. Wrote by GPT(try).

Introduction

In the digital age, the security and user-friendliness of web services are not just conveniences; they are necessities. Balancing robust security protocols with an engaging user experience is key to maintaining both the integrity and popularity of any online service. This blog post dives into the intricacies of securing web services using Nginx for authentication, coupled with designing an appealing frontend. Our journey begins with a practical scenario:

publishing a stable diffusion webUI service, accessible only to an authenticated audience.

Setting Up Nginx for Secure Authentication

Nginx excels in serving web pages and as a reverse proxy, providing enhanced security through authentication mechanisms. Let’s explore a typical Nginx configuration for secure authentication:

• /verify_token: This block forwards authentication requests to a dedicated server. By excluding the request body and focusing on essential headers, it ensures that only valid, authenticated requests proceed.

location = /verify_token {
    proxy_pass http://{your_auth_server}:2424;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
    proxy_set_header X-Original-Remote-Addr $remote_addr;
    proxy_set_header X-Original-Host $host;
}

• /login: Catering to login requests, this configuration forwards the necessary details to the authentication server, preserving crucial information about the request’s origin.

location /login {
    proxy_pass http://{your_auth_server}:2424;
    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;
}

• Error Handling (@error401): A clever redirect mechanism that guides unauthenticated users to the login page, keeping the original URL intact.

location @error401 {
    return 302 {your_domain}/login;
}

• Root Location (/): The gateway to your service, which rigorously checks each request for authentication, granting access only to verified users.

location / {
    auth_request /verify_token;
    error_page 401 = @error401;
    proxy_pass http://{your_server}:2323/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
}

This setup not only fortifies your service against unauthorized access but also maintains a seamless user experience, redirecting unauthenticated users without hassle.

Implementing JWT for Robust Backend Authentication

Implementing JWT (JSON Web Tokens) in a Flask web application provides a secure way of handling authentication. The provided Flask code demonstrates how JWT can be integrated for a robust backend authentication system:

1. Setup and Environment Variables:
   • The Flask app is configured with a secret key, essential for JWT encoding and decoding.

from flask import Flask
import os
from dotenv import load_dotenv

load_dotenv()
app = Flask(__name__)
app.secret_key = os.getenv('SECRET_KEY')

1. Login Route:
   • The /login route handles user authentication. Upon successful login, a JWT is encoded with the user’s information and expiration time, then sent as a cookie.

@app.route('/login', methods=['POST', 'GET'])
def login():
    count = update_visit_count()
    if request.method == 'POST':
        username = request.form['username']
        password = request.form['password']

        # Validate credentials (use a secure method in production)
        if username == os.getenv('chat_username') and password == os.getenv('password'):
            token = jwt.encode({
                'user': username,
                'exp': datetime.datetime.utcnow() + datetime.timedelta(minutes=30)
            }, app.secret_key, algorithm='HS256')

            response = make_response(redirect('/'))
            response.set_cookie('token', token, max_age=1800)  # Keep login status for 30 mins
            return response
        
        error = 'Invalid credentials'
        return render_template('login.html', error=error, count=count), 401
    
    # Show login page
    return render_template('login.html',count=count)

1. Token Verification:
   • A decorator token_required is used to verify the JWT token in subsequent requests. This ensures that only authenticated users can access certain routes.

def token_required(f):
    def decorator(*args, **kwargs):
        token = request.cookies.get('token')
        if not token:
            print('token is none')
            return redirect('/login')
        try:
            jwt.decode(token, app.secret_key, algorithms=['HS256'])
        except:
            print('token is invalid')
            return redirect('/login')
        return f(*args, **kwargs)
    decorator.__name__ = f.__name__
    return decorator

1. Token Validation Endpoint:
   • The /verify_token endpoint checks the validity of the token, which is essential for integrating with the Nginx authentication mechanism.

@app.route('/verify_token')
def verify_token():
    token = request.cookies.get('token')
    if not token:
        return 'Access Denied', 401

    try:
        jwt.decode(token, app.secret_key, algorithms=['HS256'])
        return 'Authorized', 200
    except:
        return 'Access Denied', 401

1. Dynamic Secret Key Update:
   • A function update_secret_key_in_env is included to update the secret key daily, enhancing security by invalidating old tokens.

# Function to generate a new secret key and write it to the .env file
def update_secret_key_in_env():
    env_file_path = '.env'
    secret_key = f'SECRET_KEY={secrets.token_urlsafe(32)}'
    last_updated = f'LAST_UPDATED={datetime.datetime.now().strftime("%Y-%m-%d")}'
    key_updated = False

    # Check if .env file exists and read the content
    if os.path.exists(env_file_path):
        with open(env_file_path, 'r') as file:
            lines = file.readlines()

        # Update or add SECRET_KEY and LAST_UPDATED
        for i, line in enumerate(lines):
            if 'LAST_UPDATED' in line:
                last_updated_date = line.strip().split('=')[1]
                if last_updated_date != datetime.datetime.now().strftime("%Y-%m-%d"):
                    lines[i] = last_updated + '\n'
                    key_updated = True
            elif 'SECRET_KEY' in line:
                if key_updated is True:
                    lines[i] = secret_key + '\n'
                else:
                    print("no need to update the secret key today")
                key_updated = True

        # If SECRET_KEY or LAST_UPDATED are not found, add them
        if not key_updated:
            lines.append(last_updated + '\n')
            lines.append(secret_key + '\n')
            key_updated = True

        # Write back to .env file
        with open(env_file_path, 'w') as file:
            file.writelines(lines)

    else: # If .env file doesn't exist, create one
        with open(env_file_path, 'w') as file:
            file.writelines([last_updated + '\n', secret_key + '\n'])
        key_updated = True

    if key_updated:
        print("Secret key and last updated date added/updated in .env file.")
    else:
        print("No update required for today.")

1. Visitor Count Feature:
   • As part of the user experience, a visitor count is maintained, which is updated with each visit.

def update_visit_count():
    try:
        with open("visit_count.txt", "r") as file:
            count = int(file.read())
        with open("visit_count.txt", "w") as file:
            count += 1
            file.write(str(count))
        return count
    except IOError:
        return "Error"

This implementation of JWT in a Flask application exemplifies a secure and efficient way of handling user authentication, ensuring that only authorized users can access protected services.

Designing a User-Friendly Frontend

In tandem with robust backend security, the frontend of your web service plays a crucial role in user engagement and satisfaction. Let’s delve into the key features of our project’s frontend design:

Theme Toggle and Slogan:

• The theme switcher allows users to choose between dark and light modes.

<div class="theme-switch-wrapper">
    <button id="theme-toggle" class="theme-toggle">
        <span class="moon">&#9790;</span>
        <span class="sun">&#9728;</span>
    </button>
</div>

• A catchy slogan is displayed, setting a creative and visionary tone.

<div class="slogan">Crafting Tomorrow's Narratives, Today.</div>

Login Interface: The entry point of any web service, the login page, is where security meets user experience. Our Flask-based web application presents a clean and intuitive login interface. It includes fields for username and password and a login button. This simplicity ensures ease of use while maintaining a professional appearance.

<form action="/login" method="post">
    <input type="email" placeholder="Username" name="username" required>
    <input type="password" placeholder="Password" name="password" required>
    <button type="submit">Login</button>
</form>

• Additional subtitle for contextual information.

<p class="subtitle">If you want to reach this server, please contact Aiken or Metis.</p>

Interactive Error Handling:

• A unique error message display using a cat image, adding a touch of humor.

{% if error %}
    <div class="error-cat">
        <img src="{{ url_for('static', filename='images/cat.webp') }}" alt="Cat">
        <div class="speech-bubble">{{ error }}</div>
    </div>
{% endif %}

Footer with Visitor Count:

• Displaying the visitor count adds an interactive and transparent element.

<footer>
    This page has been visited {{ count }} times.
</footer>

Comparing Authentication Methods: JWT, OAuth, and Basic Authentication

In the realm of web security, selecting the right authentication method is crucial. Let’s compare JWT (JSON Web Tokens), OAuth, and Basic Authentication to understand their unique features and use cases:

1. JWT (JSON Web Tokens):

   • Mechanism: Encoded tokens that carry claims and are used for secure data exchange.
   • Use Cases: Ideal for single sign-on (SSO) and stateless applications.
   • Pros: Highly flexible, supports cross-domain requests, and is self-contained with payload data.
   • Cons: Requires careful management of secret keys and token expiration.

2. OAuth:

   • Mechanism: An authorization framework allowing applications to secure designated access without revealing user credentials.
   • Use Cases: Best for third-party access (like social logins) and granting limited access to user data.
   • Pros: Enhanced security as user credentials are not exposed, and allows token-based access control.
   • Cons: Complex implementation and requires understanding of tokens and scopes.

3. Basic Authentication:

   • Mechanism: A simple authentication scheme built into the HTTP protocol using username and password.
   • Use Cases: Suitable for simple login needs, especially when accessing APIs for internal use.
   • Pros: Easy to implement and understand.
   • Cons: Less secure as it sends credentials in base64 encoded format, vulnerable to interception.

Each of these methods has its strengths and weaknesses, and the choice largely depends on the specific requirements of your web application.

Conclusion: Balancing Security and User Experience in Web Services

As we conclude this journey through securing and personalizing web services, it’s clear that the right blend of backend security and frontend design can significantly enhance both the security and user experience of a web application.

From implementing robust JWT authentication in a Flask application to designing an engaging and intuitive frontend, each aspect plays a pivotal role in delivering a seamless and secure user experience. Whether it’s the compact and scalable nature of JWTs, the interactive and user-friendly design elements on the frontend, or the comparative analysis of different authentication methods, each component contributes to a comprehensive web service solution.

For small projects, especially, the choice of JWT stands out for its efficiency, scalability, and ease of implementation, making it a wise choice for developers looking to secure their applications without compromising on performance or user experience.

In the end, the key takeaway is that security and usability do not have to be at odds; with the right tools and approaches, they can complement each other to create web services that are not only secure but also enjoyable to use.

We encourage our readers to explore the code and concepts discussed in this blog post and to visit the GitHub repository for the original code at ezEncryptYourService . Dive in, experiment, and elevate your web services to new heights of security and user engagement.

以 emby 为例，学习如何对这种自托管的服务，请求验证网站的软件进行破解，破解的整体思路分为以下的两类：

一种是改客户端，一种是改服务端。两种方式的最终原理一样，都是搭建仿冒认证服务器，客户端访问伪服务器拿到授权信息；【3】

因此无论是那种方法我们都需要搭建伪验证服务器：所以以下的操作是必须的：

1. 抓取定位到验证服务器的地址，并获取验证服务器返回的验证信息格式；
2. 使用 Nginx 搭建虚拟的验证服务器，使其返回激活/验证信息；

如果是修改客户端，则在搭建完验证站后需要：

• 修改 Host 文件，将请求验证服务器的请求劫持到本地搭建的服务上；
• 需要伪服务器和客户端都要安装自签名证书

如果是修改服务端，则后续需要：

• 修改服务端源文件，将默认的认证服务器 mb3admin.com 地址直接改成伪服务器
• 这样就不需要安装自签名证书

如果是使用 Docker 进行部署的 emby 可以使用别人修改好的服务端的镜像进行部署安装（like 开心版）

本文主要介绍验证服务器的搭建、修改客户端的方法，以及一些其他的注意事项；

Server 伪验证服务器搭建

CA 证书申请

什么是证书：什么是 SSL 认证？- SSL/TLS 认证简介 - AWS (amazon.com)

这里由于我们并没有真正拥有认证网站 md3admin 的域名故而没有对应的证书文件，因此需要为自己的服务自签发一个假的证书文件，并手动让浏览器信任该证书，保证在将该域名通过 hosts 修改转移到自己的服务上时，浏览器能正常请求该页面。

下面介绍证书的签发过程（转载自参考文献:【2】)：

mkdir -p <username>/<docker-file-path>/nginx/cert/mb3admin.com && cd <username>/<docker-file-path>/nginx/cert/mb3admin.com

# 生成 CA 密钥
openssl genrsa -out ca.key 2048 
# 生成 CA 证书
openssl req -x509 -new -nodes -key ca.key -subj "/C=CN/ST=Beijing/L=Beijing/O=<username>/OU=<username>/CN=<username>/emailAddress=<user-email>" -days 36500 -out ca.crt
# 将 CA 转换成 p12 格式，并指定密码 （<username>）
openssl pkcs12 -export -clcerts -in ./ca.crt -inkey ca.key -out ca.p12 -password pass:<username>
# 将 p12 格式的证书 Base64 编码
base64 ca.p12
# Base64 一行不能超过 76 字符，超过则添加回车换行符。如果因为换行的原因，不能安装证书，可以使用 -w 参数
base64 -w 0 ca.p12
# 将 CA 转换成 pem 格式
openssl x509 -outform pem -in ca.crt -out ca.pem
# 生成服务端私钥 server.key
openssl genrsa -out server.key 2048
# 生成服务端证书请求 server.csr
openssl req -new -sha256 -key server.key -out server.csr -subj "/C=CN/L=Beijing/O=<username>/OU=<username>/CN=mb3admin.com/CN=*.mb3admin.com"
# 生成服务端证书 server.crt
openssl x509 -req -extfile <(printf "subjectAltName=DNS:mb3admin.com,DNS:*.mb3admin.com") -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

上述代码中替换一下自己的相关信息即可（也可以直接去参考资源中获取直接执行的代码）：

• \<username\>
• \<user-email\>
• \<docker-file-path\>

生成对应证书后，对证书的操作还有以下的两步，我们首先介绍证书安装，在对 Nginx 进行配置。

• Nginx 配置：将 server.crt 和 server.key 放到 nginx 存放的地方，方便后面配置 Nginx
• 证书安装：便于浏览器后续正常访问

证书安装

双击打开证书目录中的 crt 进行证书安装，会显示“无法验证到一个受信任的证书颁发机构”，这是因为我们只是自签发并没有找第三方机构认证，不要紧直接安装即可。

没有安装证书的情况下也可能会发现验证信息正确但是激活失败的情况

这里简单介绍以下 ubuntu 信任证书的方法【2】（nas 和 ios 可参考该文）

sudo cp ca.crt /usr/local/share/ca-certificates/zhuangzhuang.crt && sudo update-ca-certificates

Nginx 设置

Nginx 可以直接在 conf.d/default.conf 中新增以下代码片段

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name mb3admin.com;

    ssl_certificate /etc/nginx/cert/mb3admin.com/server.crt;
    ssl_certificate_key /etc/nginx/cert/mb3admin.com/server.key;
	ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
    ssl_prefer_server_ciphers on;
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Headers *;
    add_header Access-Control-Allow-Method *;
    add_header Access-Control-Allow-Credentials true;

    location /admin/service/registration/validateDevice {
        default_type application/json;
        return 200 '{"cacheExpirationDays": 365,"message": "Device Valid","resultCode": "GOOD"}';
    }

    location /admin/service/registration/validate {
        default_type application/json;
        return 200 '{"featId":"","registered":true,"expDate":"2099-01-01","key":""}';
    }

    location /admin/service/registration/getStatus {
        default_type application/json;
        return 200 '{"deviceStatus":"0","planType":"Lifetime","subscriptions":{}}';
    }

    location /emby/Plugins/SecurityInfo {
        default_type application/json;
        return 200 '{"SupporterKey": "", "IsMBSupporter": true}';
    }
}

可以看到其中最为关键的是以下的几个点：

1. 设置好 servername 为验证网址的域名 mb3admin.com;
2. 将以下的域名子路径都设置为返回对应的验证信息

• /admin/service/registration/validateDevice
• /admin/service/registration/validate
• /admin/service/registration/getStatus
• /emby/Plugins/SecurityInfo

3. ssl_certificate 和 ssl_certificate_key 填写好对应的证书文件地址存放地址

Hosts 文件修改

linux 修改 host 文件地址：/etc/hosts

sudo echo "<server_ip>    <domain_address>" >> /etc/hosts

Windows 修改 host 文件地址：C:\Windows\System32\drivers\etc\hosts

....
<server_ip> <domain_address>

修改完立即刷新 dns 不需重启立即生效的方法,在 powershell 执行：

ipconfig /flushdns

Test 服务测试

完成上面的服务和 Host 修改后，可以登录对应的网站进行测试或者使用 curl 进行测试：

可以通过浏览器访问： https://mb3admin.com/admin/service/registration/validateDevice/ 或者 https://mb3admin.com/admin/service/registration/validate/ 查看返回信息是否正确；

或者在 powershell 中执行以下命令查看返回信息是否正确，这里需要注意的是可能会与 WSL2 部署的 docker 混淆，但是该指令是否生效我们还是要在宿主机上的 powershell 查看。

curl -ik https://mb3admin.com/admin/service/registration/validateDevice/

-k 参数是为了忽略证书不受信任的 https 访问安全限制导致访问失败的问题。例如如下相关报错

> Curl(60) issuer certificate is invalid 

如果使用 curl 能够正常返回，但是网页的返回信息有误，或者无法打开网页，可能就要考虑如下的原因：

• 证书信任问题，可能要看是否正确配置和安装相关证书
• 浏览器缓存问题，可以使用隐私(InPrivate)模式再次访问,或者清楚缓存后再次访问；
• 代理的问题，具体的配置如下

Clash 代理配置

若是由于设置了代理导致网站测试失败，这种情况下可以关掉代理再做测试，或者新增规则，配置验证网址不走代理。

配置规则的方法以 Clash 为例如下：

parsers: # array
    - url: <你的订阅地址>
      yaml:
        prepend-rules:
            - DOMAIN-SUFFIX,<直连的域名>,DIRECT

添加 DOMAIN-SUFFIX 设置对应的域名为直链即可；

Activate 激活

访问 emby 服务页面，在 emby premiere 选单中随便选取密钥存储即可，这里会显示无效的密钥但是不要紧，可以切换主题看看是否已经激活成功。

或者在控制台界面看是否已经有金标即可：

IOS 使用小火箭解锁 emby

详细图文请访问参考资料【5】，下面是简单的摘要：

第一步 default.conf（长按） -> 编辑纯文本，将以下代码贴到底部：

[Script]
EmbyPremiere = type=http-response,script-path=https://raw.githubusercontent.com/rartv/SurgeScript/main/EmbyPremiere/EmbyPremiere.js,pattern=^https?:\/\/mb3admin.com\/admin\/service\/registration\/validateDevice,max-size=131072,requires-body=true,timeout=10,enable=true
[MITM]
hostname = mb3admin.com

第二步 default.conf（右侧的 i 按钮） -> https解密 （界面中应该会有 mb3admin.com 的域名信息）-> 证书-> 生成新的 CA 证书 -> 安装证书 -> 系统中信任证书

第三步打开 vpn，打开 emby，信任证书选择 ok，激活完成后可以关闭小火箭，后续失效的时候再打开一次即可。

Ref 参考资料

1. 群晖上利用现有nginx搭建emby破解服务 (lengyue524)
2. Nas Emby 伪验证服务站搭建 - ZHUANGZHUANG
3. 学习 Emby 解锁及优化 - Gallen’s Blog (hgl2.com)
4. Emby全平台开心版、认证服务器设置方法 | Velaciela
5. iOS利用小火箭解锁Emby | 胡萝虎的博客 (huluohu.com)

Fi

本系列主要介绍通过公网的 ipv6 访问局域网设备并部署自己的服务供公网访问；本篇是其中的第二篇，以腾讯云和 Nginx 为例，介绍如何将服务部署到 https://域名 。

需要以下的事前准备：

• 腾讯云/阿里云/Cloudflare 等随便一个地方购买一个自己的域名
• 公网 ipv4/ipv6 地址
• 本地部署一个服务以供测试

Nginx(Docker) 安装

这里选择 Docker 来分离安装 Nginx 服务，Docker 部署的优势这里就不再赘述，这里建议使用 portainer 进行容器管理和运行状态查看。

首先创建存放 Nginx 配置文件和证书文件的目录，后续挂载给 Nginx Contrainer 使用：

mkdir -p /home/username/docker-file/nginx/conf.d
mkdir -p /home/username/docker-file/nginx/cert

配置文件存放到 conf.d 中，各种 SSL 证书则存放到 cert 文件夹中；

接着部署 Nginx，这次先不挂载目录，将 Nginx 中一些默认配置拷贝出来，以供后续使用和修改：

# run会自己执行镜像拉取，pull可以不执行
# docker pull nginx
sudo docker run --name nginx -p 80:80 -d nginx 

将配置文件复制出来：

sudo docker cp nginx:/etc/nginx/conf.d/default.conf /home/username/docker-file/nginx/conf.d/default.conf
sudo docker cp nginx:/etc/nginx/nginx.conf /home/username/docker-file/nginx/conf.d/nginx.conf
sudo docker cp nginx:/etc/nginx/mime.types /home/username/docker-file/nginx/conf.d/mime.types

基于原始的配置文件挂载后查看 nginx 是否正常运行：

sudo docker rm -f nginx
sudo docker run --name nginx -p 80:80 -p 443:443 -v /home/username/docker-file/nginx/conf.d/nginx.conf:/etc/nginx/nginx.conf -v /home/username/docker-file/nginx/conf.d/default.conf:/etc/nginx/conf.d/default.conf -v /home/username/docker-file/nginx/conf.d/mime.types:/etc/nginx/mime.types -v /home/username/docker-file/nginx/cert:/etc/nginx/cert -d nginx

参考资料：使用docker部署nginx并配置https - 逊老头 - 博客园 (cnblogs.com)

域名解析及申请免费 SSL 证书

账号应该是有50个 SSL 证书限额，但是注意每个二级域名都需要单独申请 SSL 证书，例如 aiken.Com 和 videos.Aiken.Com 需要分别申请 SSL 证书。

域名解析

注册完域名后到域名控制台，选择特定的域名进行解析：

主机记录可以设置 www 等二级域名，@既是基础域名（没有二级域名），IPV6的话设置记录类型为 AAAA，记录值这里填入公网 ipv6 地址（基于安全性考虑 Ipv6 地址大多会动态变化，包括 windows 会提供临时 ipv6 地址等等，后续会使用 DDNS-go 动态更新该地址）

SSL 证书申请

进入 SSL 证书管理界面 -> 申请免费证书 -> 提交证书申请 ->

提交证书申请界面按照指引填写即可，域名部分记得二级域名也要单独申请即可。

验证域名部分按照要求添加解析信息后点击验证域名即可，下载证书文件

耐心等待证书签发后，在我的证书界面下载证书，并将证书文件（解压后）放到挂载的 nginx 的 cert 目录中

Nginx 配置部署服务

不同服务的 Nginx 配置在细节上会有一些差别，如果基础的设置不对，可以 Google 以下 Server+Nginx 查看是否有相关的文档说明，该部分简单介绍以下基本的一些写法。

为了最大化的利用域名和单机服务，通常而言我们希望仅仅使用一个域名（包括其二级域名和二级目录）能够分别部署单机上分布于多个端口的多个服务，这里简单分别介绍如何为不同服务部署二级域名和二级目录。

需要注意的是，不同服务在部署的时候有不同的要求，有些服务涉及到一些 url 的跳转等问题，不支持二级目录的域名反代，会导致功能异常，具体需要参见相关文档，这种时候就推荐使用二级域名进行服务代理。

同时配置过程中需要注意反斜杠不要缺失，使用正确，不同的反斜杠最终会导致转向地址的不一致，参考：nginx 反向代理斜杠问题_clonetx的博客-CSDN博客

证书配置部分

证书配置部分主要按照签发处的指引，会给一个基础的模板，比如腾讯云：SSL 证书 Nginx 服务器 SSL 证书安装部署-证书安装-文档中心-腾讯云 (tencent.com)

二级地址反代：

在挂载的 conf.d 目录下的 default.conf 中新增 server 如下：

server {
     listen 443 ssl ;
     listen [::]:443 ssl;
     expires 12h;
     server_name metisy.cool;
     ssl_certificate /etc/nginx/cert/<your domain>.crt;
     ssl_certificate_key /etc/nginx/cert/<your domain>.key;
     ssl_session_timeout 5m;
     ssl_prefer_server_ciphers on;
    
    # FIXME: for safe reason disable this ---below---.
     location /dashboard/ {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Range $http_range;
        proxy_set_header If-Range $http_if_range;
        proxy_redirect off;
        proxy_pass <url_local_server_address>:<port>/;
        # the max size of file to upload
     }
}

其中

• <url_local_server_address>填写本地的局域网 ip 例如192.168.11.23
• port 则填写该 ip 对应设备上提供服务的端口，例如1234
• ssl_certificate 和 ssl_certificate_key 填写 ssl 证书对应的 crt 和 key 文件的路径

二级域名反代

在挂载的 conf.D 目录下的 default.Conf 中新增 server 如下：

server {
	listen 443 ssl ; 
	listen [::]:443 ssl;
	server_name {prefix_your domain}; 
	client_max_body_size 50000M;
	ssl_certificate /etc/nginx/cert/{prefix_your domain}.crt; 
	ssl_certificate_key /etc/nginx/cert/{prefix_your domain}.key; 
	ssl_session_timeout 5m;
	ssl_prefer_server_ciphers on;
	
	location / {
		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_set_header X-Forwarded-Protocol $scheme;
		proxy_set_header X-Forwarded-Host $http_host;
		proxy_buffering off;
		proxy_pass <url_local_server_address>:<port>/;
		#root /usr/share/nginx/html;
		#index  index.html index.htm;
	}
}

因为二级域名可以相当于一个新的域名，所以只需要把证书和 server_name 修改为新域名即可

Http 跳转Https

在挂载的 conf.D 目录下的 default.Conf 中修改最上面的 server 为如下：

server {
    listen       80 default_server;
    listen  [::]:80 default_server;
    server_name  _;
    # rewrite ^(.*)$ https://metisy.cool:443/$1 permanent;
	return       301 https://$host$request_uri;
    #access_log  /var/log/nginx/host.access.log  main;

    # location / {
    #     root   /usr/share/nginx/html;
    #     index  index.html index.htm;
    # }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

使用 return(新) 或者 rewrite(旧) 命令，将针对该域名的 http 请求都重定向到 https 中。

Alist 的反向代理

Alist 的反向代理参考如下文章：反向代理 | AList文档 (nn.ci) ，如果不修改配置的话需要将其挂载在/根路径下，否则会导致出错，二级路径会导致无法正常运行，如果要挂载到子级目录/alist/下需要按照该文修改配置文件：怎么做 | AList文档 (nn.ci)

此外，挂载完成后会发现由于 Nginx 缓存，会导致卡在登录界面无法进到主页面的问题，该问题可以通过在配置中取消缓存修复，修改 nginx 配置，添加该行：

Immich 的反向代理

为了安全性和诸多其他考虑，不支持二级目录，建议使用二级域名挂载到根目录，具体的配置参考：

• Reverse Proxy | Immich

xiaoya Alist 的反向代理

这里提一嘴，xiaoya 的 alist 的挂载目前也仅支持挂载到根路径，因此使用一个二级域名，个人暂时没找到如何挂载到子路径下，欢迎指正，万分感谢。

而如果是 xiaoya 的 emby 的反向代理，则需要手动重新映射一下 strm 资源库目录下的播放直链，将其改为挂载小雅的公网地址，可以使用以下脚本批量修改：

find /home/user-dockerfile-dir/emby_res/xiaoya -name "*.strm" -exec sed \-i "s#http://{locahost}:{port}#https://{domain}/#g; s# #%20#g;     s#|#%7C#g" {} \;

这里的{localhost} {port} {domain}请自行修改成自己的对应地址，这样挂载出来的 emby 就可以在公网进行播放了。

重启 Nginx

完成上述所有对应的配置后，启动 Nginx，即可实现 https 访问对应的网站了。

# 可以删除当前contrainer重新部署
docker rm -f nginx
sudo docker run --name nginx -p 80:80 -p 443:443 -v /home/username/docker-file/nginx/conf.d/nginx.conf:/etc/nginx/nginx.conf -v /home/username/docker-file/nginx/conf.d/default.conf:/etc/nginx/conf.d/default.conf -v /home/username/docker-file/nginx/conf.d/mime.types:/etc/nginx/mime.types -v /home/username/docker-file/nginx/cert:/etc/nginx/cert -d nginx

但是实际没必要那么麻烦，直接执行：

docker restart nginx

即可，观察容器是否正常运行，如果运行失败查看 log 看是否哪里配置出错。

参考资料：

• Nginx通过二级目录（路径）映射不同的反向代理，规避IP+端口访问 | 张戈博客 (zhang.ge)
• Docker Nginx 配置安装 SSL 证书（支持 Https 访问） - 犬小哈教程 (quanxiaoha.com)
• 基于网盘挂载的emby服务端并实现直链播放 - syqman折腾笔记 基于小雅的方式的话无需参考该文，仅需将 address 文档替换成公网连接即可。
• 小雅Emby反代
• nginx反向代理关闭缓存 (baidu.com)
• Reverse proxy using NGINX - Community Guides - Home Assistant Community (home-assistant.io)

TroubleShooting 问题解决

Bug

访问域名 Nginx 显示 504 超时 error，直接使用局域网 ip 访问各个服务并无超时现象，各个服务运行正常，Nginx 使用默认页面也能正常访问。

怀疑是由于 Docker、Windows、WSL2 更新之后网络的问题，导致 wsl2 可以访问各个局域网，但是 nginx 的 container 无法对各个局域网上的服务进行访问，因此采用 windows 宿主机直接安装 nginx 来避免此类网络问题，将 Nginx 添加到启动服务中，并将 WSL2 中的 nginx 配置迁移过来即可。

WIN+R shell:starup 可打开启动文件夹，建立 nginx 的快捷方式后就可以在任务管理器中设置为启动项了。

Fi

本章就到这边，下一章节讲解由于 Ipv6 的动态特性，需要部署动态域名解析服务，这里以 ddns-go 为例，自动更新对应域名解析中的主机记录值。