That sounds pretty technical. Can I check with a script?
Thanks, Jos
You can run
cat /proc/sys/net/ipv6/flowlabel_state_ranges
or
sysctl net.ipv6.flowlabel_state_ranges
on a Linux device.
Are you able to run those commands on the proxmox host?
Yes:
cat /proc/sys/net/ipv6/flowlabel_state_ranges
0
Some additional checks on IPv6 @ Imgur: The magic of the Internet
I appologise for my earlier diagnosis that the flow label was involved. This appears to be dependent on the source port (and possibly address) as using the following source ports from 2a0a:ef40:1827:f101:6ce4:3818:306b:586e reproducably succeeds
1025 1027 1028 1030 1032 1034 1037 1039 1040 1042 1045 1047 1049 1051 1052 1054 1056 1058 1061 1063 1065 1067 1068 1070 1073 1075 1076 1078 1080 1082 1085 1087 1088 1090 1093 1095 1097 1099 1100 1102 1105 1107 1108 1110 1112 1114 1117 1119 1121 1123 1124 1126 1128 1130 1133 1135 1136 1138 1141 1143 1145 1147 1148 1150 1152 1154 1157 1159 1161 1163 1164 1166 1169 1171 1172 1174 1176 1178 1181 1183 1185 1187 1188 1190 1192 1194 1197 1199 1200 1202 1205 1207 1209 1211 1212 1214 1217 1219 1220 1222 1224 1226 1229 1231 1232 1234 1237 1239 1241 1243 1244 1246 1248 1250 1253 1255 1257 1259 1260 1262 1265 1267 1268 1270 1272 1274 1277 1279 1281 1283 1284 1286 1288 1290 1293 1295 1296 1298 1301
Connections from the following ports from 2a0a:ef40:1827:f101:6ce4:3818:306b:586e reproducably fail
1024 1026 1029 1031 1033 1035 1036 1038 1041 1043 1044 1046 1048 1050 1053 1055 1057 1059 1060 1062 1064 1066 1069 1071 1072 1074 1077 1079 1081 1083 1084 1086 1089 1091 1092 1094 1096 1098 1101 1103 1104 1106 1109 1111 1113 1115 1116 1118 1120 1122 1125 1127 1129 1131 1132 1134 1137 1139 1140 1142 1144 1146 1149 1151 1153 1155 1156 1158 1160 1162 1165 1167 1168 1170 1173 1175 1177 1179 1180 1182 1184 1186 1189 1191 1193 1195 1196 1198 1201 1203 1204 1206 1208 1210 1213 1215 1216 1218 1221 1223 1225 1227 1228 1230 1233 1235 1236 1238 1240 1242 1245 1247 1249 1251 1252 1254 1256 1258 1261 1263 1264 1266 1269 1271 1273 1275 1276 1278 1280 1282 1285 1287 1289 1291 1292 1294 1297 1299 1300
This could indicate that a load balancer is being used.
Why do you think that? I gave examples of IPv6 connections failing that were not coming from Let's Encrypt servers.
Let's Debug runs tests from its own server and using Let's Encrypt's staging system. The tests from its own server (in Finland I believe) fails consistently see result here: Let's Debug
I tried again this morning from my own test server in an AWS region on US East Coast. I am connecting to your home page using the IPv6 address in the public DNS for your domain
Name: devrijegeest.nl
Address: 188.213.94.112
Address: 2a10:3781:44a3:1::54
Source IP for IPv6 tests: 2600:1f18:4446:e90b:2692:1d8b:7912:26ec
(don't try tracing it back - test server has been rotated out)
Running four IPv6 curl requests immediately after each other.
2 of 4 timeout
curl -i6 -m8 http://devrijegeest.nl
curl: (28) Operation timed out after 8001 milliseconds with 0 bytes received
curl -i6 -m8 http://devrijegeest.nl
HTTP/1.1 302 Found
Date: Sun, 02 Aug 2026 13:25:05 GMT
Server: Apache/2.4.68 (FreeBSD) OpenSSL/3.5.6 PHP/8.4.23
Location: https://devrijegeest.nl/
curl -i6 -m8 http://devrijegeest.nl
HTTP/1.1 302 Found
Date: Sun, 02 Aug 2026 13:25:07 GMT
Server: Apache/2.4.68 (FreeBSD) OpenSSL/3.5.6 PHP/8.4.23
Location: https://devrijegeest.nl/
curl -i6 -m8 http://devrijegeest.nl
curl: (28) Operation timed out after 8001 milliseconds with 0 bytes received
After that I ran 15 back to back tests using IPv4
All of them succeeded
Oh, and I already addressed that. Let's Encrypt will fallback to IPv4 if IPv6 times out but only for the first HTTP request. It does not retry IPv6 timeouts after you redirect the original HTTP request anywhere. Which you do as you redirect it to HTTPS.
You could reconfigure your Apache server so it does not redirect incoming ACME Challenge URLs. But, that would not help the more general problem of people not being able to reach you on IPv6.
I provided this earlier too but perhaps worth a review. There is no reason for Let's Encrypt to modify this behavior given you can just not redirect the challenge, or remove AAAA from the public DNS. Or, better yet get IPv6 working reliably 
Thanks y'all for your effort and interesting replies.
Will search further for a solution or just discontinue IPv6.