nginx之403错误-写权限不足 0x0 前段报错后，通过浏览器F12查看是403错误，于是登录 tengine 查看日志，确发现 access 一度没有看到相关的请求，怀疑是没有经过此 tengine、甚至是客户端错误，但从浏览器内 403 返回内容否定了这点，因为 403 的内容是 tengine 返回的。 那么这是怎么回事呢？ 通过在浏览器内请求指定的 url，发现 access 日志能匹配到，那么日志是没问题的，由于响应的是 tengine 返回，所以应该也没有 waf 拦截。 在尝试了多次方案之后，仍然没有找到请求，于是尝试查看 error 日志，发现此请求会要求写缓存，但是缓存无权限写入报错。 猜测是 nginx 无权限写文件，于是为了标识是权限问题，所以返回了 403 ，所以这个问题教会我们的是，我们总以为服务正常情况下能记录所有日志，因为基本上 4xx、5xx日志都会记录下来，而现在可以知道，就算是 nginx、web都没问题，日志不一定能记录所有请求，可能会因为 nginx 内部错误、甚至可能是操作系统级别的错误导致异常，而无法记录下日志。

mat脚本ParseHeapDump.sh之cannot open display 0x1 错误 在导出 jvm 内存转储后使用mat工具进行分析，但是在执行 ParseHeapDump.sh 后提示如下错误: cannot open display 尝试了很多办法，其中包括去掉所有参数直接执行此脚本，以及执行脚本实际调用的命令 MemoryAnalyzer，又或者更换 JDK 版本，都是报错的这个内容。在根据 mat 的相关内容进行搜索，也没有解决办法 最后通过 display 的关键字搜索出来了解决方案，如下: export DISPLAY=:0 xset q 参考文档如下： https://askubuntu.com/questions/476036/xset-unable-to-open-display 那么为什么会出现这种情况呢？相信弄清楚 DISPLAY=:0 就可以了，有一些难以理解的解释: Explicitly setting DISPLAY=:0 is usually a way to access a machine's local display from outside the local session, such as over a remote access or from a cron job :0 is usually the local display (i.e. the main display of the computer when you sit in front of it). :1 is often used by services like SSH when you enable display forwarding and log into a remote computer. It can also be modified by startup scripts which try to "fix" it. To find out whether this is happening, run grep DISPLAY ~/.??* .??* is a trick to get all dot files without .. and . (parent and current folder). If that doesn't print anything, check /etc/profile,/etc/bash* and /etc/bash*/* in a similar manner. I couldn't find a useful manual for xmacro but most X11 application support the option -d or -display to override $DISPLAY.

v2ray/v2fly的安装使用以及加速 0x0 重点如下： 系统推荐 centos7.9 安装bbr魔改版加速（bbr和锐速lotserver二选一，推荐bbr） wget -N --no-check-certificate "https://raw.githubusercontent.com/chiakge/Linux-NetSpeed/master/tcp.sh" && chmod +x tcp.sh && ./tcp.sh 选择安装bbr/bbr魔改版，安装后重启 重启后仍然执行脚本 ./tcp.sh 选择使用bbr魔改版，之后下面会提示已经安装bbr和开启bbr加速模块则成功，或者可以使用以下命令确认 # 结果返回 tsunami 或 bbr sysctl net.core.default_qdisc # 结果返回 fq sysctl net.ipv4.tcp_available_congestion_control 安装v2ray curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh > install-release.sh # 默认安装最新版，可以指定版本 ./install-release.sh --version v5.1.0 v2ray配置参考 /usr/local/etc/v2ray/config.json { "log": { "loglevel": "info", "access": "/var/log/v2ray/access.log", "error": "/var/log/v2ray/error.log" }, "inbounds": [ { "port": 10000, "listen":"127.0.0.1",//只监听 127.0.0.1，避免除本机外的机器探测到开放了 10000 端口 "protocol": "vmess", "settings": { "clients": [ { "id": "7ec9de15-4147-4121-848b-1fcbb7fc5624", "alterId": 0 } ] }, "streamSettings": { "network": "ws", "wsSettings": { "path": "/xxx" } } } ], "outbounds": [ { "protocol": "freedom", "settings": {} } ] } 如果是安装较高的版本，可能提示系统版本太低，可以选择升级到较高版本 安装nginx，安装过程略，配置如下 server { listen 443 ssl; ssl_certificate /opt/domain.crt; ssl_certificate_key /opt/domainname.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; server_name fd.xxx.com; #与 V2Ray 配置中的 path 保持一致 location /xxx { proxy_redirect off; #假设WebSocket监听在环回地址的10000端口上 proxy_pass http://127.0.0.1:10000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

群晖7.1.1版本媒体播放器方案 0x1 现状 升级到群晖7.1.1后，ds video没什么问题，但是不再像以前方便的安装解码器了，会影响一些视频的转码和音频，说简单点很多视频要么不能播放，要么播放没声音。 而根据网上的一些文档安装解码器，步骤：洗半白、安装破解AME、安装ffmpeg、安装破解解码。但是结果无效。 0x2 emby 折腾了许久仍然不行，那么不再使用ds video了，使用其他替换也是一样的，其中有 jellyfin，emby，plex。其中第一个是完全免费，是emby的开源版，后两个收费。这里选择 emby PS 一开始选择的群晖套件版本的 meby，但是实际测试手动刮削内容不出来，查看 emby 日志超时，及时群晖设置网络代理，所以最后更换为 docker 的方式安装 emby ，刚好也有提供好的快乐版，在 dockerhub 下载好镜像后，启动命令如下: docker run \ -p '8096:8096' \ -p '8920:8920' \ -p '1901:1900/udp' \ -p '7359:7359/udp' \ -v /volume2/docker/emby/config:/config \ -v /volume2/docker/emby/data:/data \ -v /volume2/video:/data/video \ -e TZ="Asia/Shanghai" \ --device /dev/dri:/dev/dri \ -e UID=0 \ -e GID=0 \ -e GIDLIST=0 \ --restart always \ -e HTTP_PROXY="http://192.168.0.10:8001" \ -e HTTPS_PROXY="http://192.168.0.10:8001" \ --name emby \ -d lovechen/embyserver:latest 其中 1900 貌似是 DLAN 端口，但是我本机被占用了，所以更换为 1901 了。目录方面基本上就创建好 config 和 data 即可。再就是本机的 视频 目录需要挂载上去，用于后续添加媒体库

j3455-itx升级到群晖7.1.1版本系统 0x1 升级方式 之前黑群晖的方法都是使用网上提供的引导，刻录后再安装系统。虽然看起来不麻烦，但是引导版本相当重要，需要跟你的硬件匹配，需要跟系统匹配。所以基本上你能安装什么系统，取决于人家提供的版本，相当有局限性。 NEW 现在通过arpl即可动态的编译引导，之后就可以启动成功，arpl是巴西的以为大佬开发，git地址如下： https://github.com/fbelavenuto/arpl 原版已经不怎么更新了，现在国内大神根据原版做了符合国情的版本 在线编译的版本如下： https://github.com/wjz304/Redpill_CustomBuild 手动构建的版本: https://github.com/wjz304/arpl-i18n 在后续的版本中，推荐还是使用手动构建的版本，这样需要填入的参数更少 使用repl构建引导 构建引导参考如下步骤： 前置配置，比如我的cpu是j3455，需要有一些特别的bios设置，还有bios针对linux的补丁，这些不论是使用什么引导都需要配置的 在git下载最新的镜像，解压得到img镜像 使用刻录工具把镜像刻录进入U盘，作为引导盘 接好所有的设备，群晖后续可能使用的，repl构建需要识别这些设备和接口，特别是硬盘、网线都要插好 U盘启动后选择配置，根据向导选择构建的机型、系统版本等信息。我j3455机器原来安装的ds918+ 6.2的系统，实际测试选择ds920+ 7.1.1没有问题。 选择构建后会自动下载引导程序并且构建为合适的引导，完成后会多一个重启到引导的选项 选择重启即可 接下来使用群晖的扫描工具，便可以在局域网找到机器 安装系统 找到机器后可以开始安装新版本系统了，下载新版本系统地址，根据系统版本下载： https://www.synology.cn/zh-cn/support/download 千万不要找到下面这个地址去了： https://archive.synology.com/download/Os/DSM/ 这个是引导的下载地址，不过下载后应该是不能安装成功的 PS. 最后出现的几个问题，记录： 选择镜像安装系统阶段，过了多个10分钟一直没有安装成功 需要把nas联网断开，可能是上传了镜像，但是仍然可能通过互联网下载某些安装包了，断开互联网，重启机器后重新选择安装速度正常 20240730 arpl 在github中拿掉了代码，并且没有更新了，但还是有一些小伙伴找到了最新资料的，试试根据下面文档升级到 7.2 版本吧 https://www.mspace.cc/archives/1002