有关甲苯的危险品分类 根据您提供的两份SDS（安全技术说明书），虽然两者均含有35%的甲苯作为主要危害成分，但运输分类编码不同（UN 1866 与 UN 1294），这主要是由于产品的整体性质、次要成分、物理形态和用途在运输分类中的综合评估差异所致。以下是具体分析：1. UN 编号的基本含义UN 1294：通常指“甲苯混合物”或“含甲苯的混合物”，适用于以甲苯为主要溶剂的混合物。UN 1866：通常指“树脂溶液”，适用于含有树脂、溶剂（如甲苯）的混合体系，其整体性质更偏向“树脂类产品”。2. 两个产品的关键区别项目POLYESTER RESIN 1318XX（UN 1866）EPICLON HPC-8000-65T（UN 1294）产品名称聚酯树脂溶液（Polyester resin solution）聚酯树脂溶液（Polyester resin solution）主要溶剂甲苯（35%）甲苯（35%）次要成分聚合物（65%）聚合物（65%）运输名称树脂溶液（RESIN SOLUTION）甲苯混合物（TOLUENE mixture）分类依据更强调“树脂体系”的整体性质更强调“含甲苯的混合物”的溶剂特性附加信息无特别说明附有新化学物质简易申报说明（中国 MEP Order 7）3. 可能的原因分析产品整体性质差异： 虽然两者均为聚酯树脂溶液，但可能在粘度、挥发性、用途（如半导体材料的具体工艺）或配方细节上有所不同，导致在运输分类时被归入不同类别。运输分类的侧重点不同：UN 1866 更适用于“树脂、溶液类”产品，强调其整体易燃性和树脂特性。UN 1294 更适用于“甲苯或含甲苯混合物”，强调其溶剂易燃性。法规或申报差异： MSDS002 中明确提到该产品含有“新化学物质”，并已根据中国《新化学物质环境管理办法》完成简易申报。这可能意味着该产品的配方或用途在某些法规框架下被特别归类，影响其运输编码。4. 建议如果您在运输、储存或合规管理中需要明确分类依据，建议：联系生产商（DIC Corporation），确认两个产品在配方、用途或运输分类上的具体差异。根据实际运输方式（如海运、空运、陆运）查阅最新的《联合国危险货物运输建议书》（UN Model Regulations）或《国际海运危险货物规则》（IMDG Code），确认具体条目适用性。在中国境内运输时，应同时遵守《危险化学品目录》及相关运输规定，确保标签、包装与UN编号一致。总结虽然两份SDS中甲苯含量相同，但产品的整体性质、次要成分、用途及法规申报状态可能导致其在危险货物运输分类中被赋予不同的UN编号。这种差异在化学品分类中是常见的，关键是要确保在实际运输和使用中符合对应的安全规范和标签要求。如果您需要进一步协助解读SDS中的其他部分或运输合规问题，我可以继续为您分析。

window nginx使用power shell分割日志 在window下使用nginx，一般网上推荐编写bat文件或者lograte的Windows版来分割日志。经过实践，直接使用power shell脚本更加方便，同时也不需要对nginx作出任何操作，提高服务的稳定性。$nginxExePath = "C:\Users\ECSadmin\Documents\nginx-1.27.1.1\nginx.exe" $nginxLogPath = "C:\Users\ECSadmin\Documents\nginx-1.27.1.1\logs\access.log" $nginxRootDir = "C:\Users\ECSadmin\Documents\nginx-1.27.1.1" $backupDir = "D:\logs_backup" $daysToKeep = 10 New-Item -Path $backupDir -ItemType Directory -Force | Out-Null if (Test-Path $nginxLogPath) { $nginxBackupName = "nginx_access_$(Get-Date -Format 'yyyyMMdd').log" Copy-Item $nginxLogPath "$backupDir\$nginxBackupName" -Force Set-Content $nginxLogPath -Value $null -Force } Get-ChildItem $backupDir | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$daysToKeep) } | Remove-Item -Force

Emby 反代后外网访问慢的解决方案 由于一台服务器上部署了多个服务，所以 Emby 只能通过域名区分进行访问。为了解决这个问题，我通过 Nginx 对 Emby 进行反向代理。然而，反代后发现 Emby 在内网可以瞬间加载视频，但在外网加载速度非常慢，甚至会出现视频未播放完就跳跃的问题。问题描述通过抓包分析发现，Nginx 反代 Emby 后，请求媒体的响应状态码是 200；而在内网直接访问（与 Emby 在同一网段）时，请求媒体的响应状态码是 206。Nginx 反代 Emby，此时请求视频媒体的响应状态码是 200:家里直接访问（与 Emby 在同一网段），此时请求视频媒体的响应状态码是 206:状态码解释200 OK：表示请求成功，服务器已成功处理了请求。对于 GET 请求，响应包含所请求的资源。206 Partial Content：表示服务器已成功处理了部分 GET 请求。通常用于支持范围请求，客户端可以请求资源的一个或多个部分。解决方案经过排查发现，这是因为 Nginx 反代 Emby 时进行了缓存，并且不允许只处理部分请求。解决方法是在 Nginx 反代配置中加入如下配置：proxy_buffering off; proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range;

NGINX反代EMBY 原因：洁癖，第三方修改可能存在安全问题。优点：支持原版最新镜像，不修改服务端、不下载第三方插件、不修改客户端，不劫持网络。思路：使用 Nginx 反向代理 Emby，并替换 JS 中激活服务器地址。下面是我使用宝塔反代的Nginx 配置client_max_body_size 5000M; 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 Sec-WebSocket-Extensions $http_sec_websocket_extensions; proxy_set_header Sec-WebSocket-Key $http_sec_websocket_key; proxy_set_header Sec-WebSocket-Version $http_sec_websocket_version; proxy_cache off; proxy_redirect off; proxy_buffering off; location / { proxy_pass http://192.168.2.1:8096;# Emby服务器地址 proxy_set_header X-Forwarded-For $remote_addr; proxy_ssl_verify off; proxy_http_version 1.1; proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 86400; } location ~* \.(gif|png|jpg|css|js|woff|woff2)$ { proxy_pass http://192.168.2.6:8097; # Emby服务器地址 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 REMOTE-HOST $remote_addr; expires 12h; # 图片缓存浏览器过期时间 } # 替换指定 JS 文件的激活服务器地址为本地 location ^~ /web/modules/emby-apiclient/connectionmanager.js { proxy_pass http://192.168.2.6:8097; # 通用代理头设置 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 替换激活服务器地址 sub_filter 'https://mb3admin.com/' '/'; sub_filter_once off; # 只替换 JS 类型的文件 sub_filter_types application/javascript application/x-javascript; } # 模拟激活服务器响应 location ^~ /admin/service/registration/validateDevice { default_type application/json; add_header Content-Type application/json; return 200 '{"cacheExpirationDays":365,"message":"Device Valid","resultCode":"GOOD"}'; } # 修正秘钥页面填写问题（可省略） location ^~ /Plugins/SecurityInfo { default_type application/json; add_header Content-Type application/json; return 200 '{"SupporterKey":"请体验后支持正版","IsMBSupporter":true}'; }另外一组普通配置：server { listen 80; server_name xxx.com;#你的域名 client_max_body_size 6000M; 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 Sec-WebSocket-Extensions $http_sec_websocket_extensions; proxy_set_header Sec-WebSocket-Key $http_sec_websocket_key; proxy_set_header Sec-WebSocket-Version $http_sec_websocket_version; proxy_cache off; proxy_redirect off; proxy_buffering off; location / { proxy_pass http://127.0.0.1:8080;#反代域名 proxy_set_header X-Forwarded-For $remote_addr; proxy_ssl_verify off; proxy_http_version 1.1; proxy_set_header Host 127.0.0.1:8080;#反代域名 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 86400; } }

nginx在vps上使用sytemctl管理的小问题 安装nginx后，采用sytemctl管理，在开始和重启的时候都会提示类似open() "/run/nginx.pid" failed (13: Permission denied)网上搜索发现，很多帖子都在说要检查nginx配置文件中pid位置和service中是否一致。nano /usr/lib/systemd/system/nginx.service nano /etc/nginx/nginx.conf发现pid文件路径没有问题。后来发现一篇文章中提到，在service文件中生成pid文件语句后面加入ExecStartPost=/bin/sleep 0.1意思是延迟0.1秒启动，然后就一切正常了。可能是由于小机子性能比较弱，I/O延迟太大。顺便在启动命令前又加了一句ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf整体文件内容如下：[Unit] Description=nginx - high performance web server Documentation=https://nginx.org/en/docs/ After=network-online.target remote-fs.target nss-lookup.target Wants=network-online.target [Service] Type=forking PIDFile=/var/run/nginx.pid ExecStartPost=/bin/sleep 0.1 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf ExecReload=/bin/sh -c "/bin/kill -s HUP $(/bin/cat /var/run/nginx.pid)" ExecStop=/bin/sh -c "/bin/kill -s TERM $(/bin/cat /var/run/nginx.pid)" [Install] WantedBy=multi-user.target重启systemctl服务。systemctl daemon-reload就可以正常管理nginx了。